Concerto on the Raspberry Pi

[august]

Hi everyone,
   As a good number of the posts to the group revolve around Concerto's compatibility and use with the Raspberry Pi, I wanted to set up this "sticky" discussion at the top of the group so new users coming by will see it. This is a discussion, not an announcement, as doubtless the new Concerto frontend will perform differently and people will find workarounds and improvements to improve Concerto on the pi.

  From the beginning with Concerto 1 in 2007 or so, the graphical performance of transitions for Concerto has been a challenge. My observations in the course of doing deployments suggest that a good 2D graphics chipset is essential. As shown on concerto-signage.org, the current favorite is the Intel GMA950. It and its related chipsets have shown to perform reasonably well with Concerto. While RAM and a decent CPU are great, it has been the graphics chipset that has proven decisive when it comes to performing graphical transitions.

  The Raspberry Pi, while a wonderful vehicle for learning and experimentation, is, without extensive optimization, unsuitable for displaying the Concerto frontend. This is due primarily to its small RAM and barebones graphical chipset.

   The Pi's lack of RAM has become most apparent with our current frontend. As documented in the issue tracker, the current frontend has a moderate memory leak which in many cases will hang the display after a time. While this can be delayed with larger amounts of RAM or avoided with periodic automatic reboots, it tends to affect the pi's most because of the tiny amount of RAM they have (256-512MB). While at least 2GB of RAM is definitely recommended for Concerto, the upcoming Dart-based frontend is likely to at least diminish this problem on the pi.

  Matters in the graphics department are probably less susceptible to improvement. If users are willing to endure jerky or non-existent graphical transitions, this may be alright, but without substantially better 2D rendering performance, this will be a major issue with Concerto and the Pi going forward.

  I would not recommend the Raspberry Pi for any but experimental use with Concerto. While custom optimizations may improve matters with the Concerto frontend, anyone who wants Concerto to work reasonably well out of the box would be better served by a computer with a dedicated graphical chipset with good 2D performance and quite a bit of RAM.

  All of this said, I myself have yet to do anything extensive with the Pi and Concerto and base this on my previous experience with deploying Concerto on limited hardware and the posts to this group. Your feedback, workarounds, optimizations, and other input are invaluable to others trying to get a deployment up and running and potentially our being able to improve Concerto itself.


 --
August

[Brian Michalski]

I'll chime in to offer a slightly less pessimistic viewpoint; August is notorious for dismissing "toy" technology (like wifi)...

Concerto 1.9.x isn't actively developed, I know the the frontend / player JavaScript has a few small memory leaks.  Most browsers didn't pick up on these when we were writing the code back in 2007(?), but I don't know how future proof the memory profile is as Firefox and Chrome keep evolving... that old code isn't keeping up.

Raspberry Pi, and other lower performance platforms, tend to exacerbate any memory leaks or CPU intensive code that we run.  That said, I don't completely write these platforms off as losses.  With the right maintenance, like regular reboots, and some appropriate expectations (sry, not going to drive a 4K screen crossfading videos every second) I think they're an acceptable low-cost driver for a display.  I would set pretty reasonable content durations to try and minimize the overlap and try a different number of fields on your template if 4 is too much. A Raspberry Pi computer might even be able to run the v1 PHP server, but v2 is probably out of the question unless you're a RoR tuning expert.

Transitions, as August mentions, are the bane of my existence when working on the frontend.  In 1.9.x, we're using timers to increment/decrement the opacity value of some dom elements.  In the current v2 stuff we're doing the same thing with a lot of abstraction in between (compliments of Google Closure).

For the new v2 frontend we're switching to CSS animations which hope to be more efficient and leverage whatever GPU a platform has available.  I don't know yet if the overhead of (web components + css animations) > (less efficient but more "classical" approach).  Monitoring the FPS [1] would be an interesting test if someone is up for it. Additionally, V2 has/will have a no transition mode which will just jump over to the next piece of content; not pretty, but certainly easier all around.

Finally, my gut says that if you can play Doom or Quake on a Raspberry Pi you must be able to run a digital signage system. We made a choice to develop web browser based frontends first because it gives us the best cross-platform support with the least amount of overhead, but there's no reason native apps can't emerge just like the V1 Screensaver.  We've considered going this path for Android and iOS apps but haven't had spare developer cycles to pick this up... a Linux native app (Qt? perhaps I don't know what I'm talking about here) could certainly emerge.  If anyone has ideas to kill all these birds with one stone please let me know.

~Brian M

[1] https://developer.chrome.com/devtools/docs/tips-and-tricks#counter-display.  It would also be neat to instrument this in JavaScript to collect and report performance data automatically across different platforms, but that's much harder than just looking at a display.

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concerto-digital-s...@googlegroups.com.
To post to this group, send email to concerto-dig...@googlegroups.com.
Visit this group at http://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

[drich]

I would also argue that if you can run XBMC on the bloody thing you should be able to do just about anything with video or static images.

That said, how complex is the API to talk to the concerto server for a stand-alone app? I haven't done any "real" programming in years (mostly python scripts and tools theses days), but I would be interested in seeing just what the level of effort would be to build something to replace running a web browser.

 

---
Dan Rich <dr...@employees.org> |   http://www.employees.org/~drich/
                               |  "Step up to red alert!"  "Are you sure, sir?
                               |   It means changing the bulb in the sign..."
                               |          - Red Dwarf (BBC)

[August]

Certainly a native app connecting to Concerto could perform well, although XBMC is an interesting example. About a year back, I tried out one of the Android TV-connected devices that are out there. It was totally unable to run XBMC. But for my next try, I found a unit that had the backing of one of the XBMC developers, and with the help of a code fork and a bunch of optimizations, it was able to run pretty well. But even those modest boxes (like the Pivos) have 2-3x the CPU and RAM of a pi.

But that's really not the issue with Concerto. When we first set out with v1, we made the conscious decision to use the web browser as a frontend because we felt that the computing power curve would keep up with things (and it did). We didn't really foresee the revolution in mobile devices setting those numbers back a year or two, and certainly didn't foresee irrationally-cheap computing setting it back a decade. Additionally, writing a frontend in something like OpenGL seemed (in our novice experience with it) to present difficulties in terms of having a CSS analog how to lay out content and do proper content presentation and typography.

If your content needs are relatively known and simple (say a single image on the screen), some native development could be workable. I suspect, though, that those efforts will far outweigh the cost of even a modest Android setup. Now while it's not yet a substitute for the SFF PC's we recommend, Android is an open-ish platform that above and beyond Webviews, may see done to optimize Concerto over time given its popularity, to say nothing of the ever-increasing performance of Android devices (more so than a pi, just because of manufacturing scale).

Just please, don't use Raspberry Pi's for anything serious or production unless you're really into playing the low-level optimization game, in which case, we'd love to see it on Github.

--
August

drich

January 6, 2015 at 4:56 PM

I would also argue that if you can run XBMC on the bloody thing you should be able to do just about anything with video or static images.

That said, how complex is the API to talk to the concerto server for a stand-alone app? I haven't done any "real" programming in years (mostly python scripts and tools theses days), but I would be interested in seeing just what the level of effort would be to build something to replace running a web browser.

 

---
Dan Rich <dr...@employees.org> | http://www.employees.org/~drich/
| "Step up to red alert!" "Are you sure, sir?
| It means changing the bulb in the sign..."
| - Red Dwarf (BBC)

On 2014-12-30 21:51, Brian Michalski wrote:

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concerto-digital-s...@googlegroups.com.
To post to this group, send email to concerto-dig...@googlegroups.com.
Visit this group at http://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

Brian Michalski

December 31, 2014 at 12:51 AM

I'll chime in to offer a slightly less pessimistic viewpoint; August is notorious for dismissing "toy" technology (like wifi)...

Concerto 1.9.x isn't actively developed, I know the the frontend / player JavaScript has a few small memory leaks.  Most browsers didn't pick up on these when we were writing the code back in 2007(?), but I don't know how future proof the memory profile is as Firefox and Chrome keep evolving... that old code isn't keeping up.

Raspberry Pi, and other lower performance platforms, tend to exacerbate any memory leaks or CPU intensive code that we run.  That said, I don't completely write these platforms off as losses.  With the right maintenance, like regular reboots, and some appropriate expectations (sry, not going to drive a 4K screen crossfading videos every second) I think they're an acceptable low-cost driver for a display.  I would set pretty reasonable content durations to try and minimize the overlap and try a different number of fields on your template if 4 is too much. A Raspberry Pi computer might even be able to run the v1 PHP server, but v2 is probably out of the question unless you're a RoR tuning expert.

Transitions, as August mentions, are the bane of my existence when working on the frontend.  In 1.9.x, we're using timers to increment/decrement the opacity value of some dom elements.  In the current v2 stuff we're doing the same thing with a lot of abstraction in between (compliments of Google Closure).

For the new v2 frontend we're switching to CSS animations which hope to be more efficient and leverage whatever GPU a platform has available.  I don't know yet if the overhead of (web components + css animations) > (less efficient but more "classical" approach).  Monitoring the FPS [1] would be an interesting test if someone is up for it. Additionally, V2 has/will have a no transition mode which will just jump over to the next piece of content; not pretty, but certainly easier all around.

Finally, my gut says that if you can play Doom or Quake on a Raspberry Pi you must be able to run a digital signage system. We made a choice to develop web browser based frontends first because it gives us the best cross-platform support with the least amount of overhead, but there's no reason native apps can't emerge just like the V1 Screensaver.  We've considered going this path for Android and iOS apps but haven't had spare developer cycles to pick this up... a Linux native app (Qt? perhaps I don't know what I'm talking about here) could certainly emerge.  If anyone has ideas to kill all these birds with one stone please let me know.

~Brian M

[1] https://developer.chrome.com/devtools/docs/tips-and-tricks#counter-display.  It would also be neat to instrument this in JavaScript to collect and report performance data automatically across different platforms, but that's much harder than just looking at a display.

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concerto-digital-s...@googlegroups.com.
To post to this group, send email to concerto-dig...@googlegroups.com.
Visit this group at http://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

august

December 30, 2014 at 11:20 PM

[Kenley Cheung]

Bringing this thread back to kickstart documenting the Frontend APIs used by the Frontend/Player JS.

I've started a wiki to facilitate a knowledge transfer:

https://github.com/concerto/concerto-frontend/wiki/Frontend-Server-API

Dan, if you're inclined to help out, feel free to poke around at the URLs mentioned in the wiki.  The JSONView browser extension and Chrome Web Inspector may help you out here:

http://jsonview.com/

Everything is exposed in a machine readable format if anyone wanted to build a native Frontend application.  I won't speak for the entire Concerto team, but this API should be stable for V2 in case anyone writes an native Frontend to consume it.

--

Kenley Cheung

[rober...@gmail.com]

Not sure if this is relevant, but it seems from this article that Chromium, compiled with GLES 2.0 support, can offload some of the rendering load to the GPU...
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome

Would this apply to the Videocore 4 GPU? I do not know.  Anyone have an idea of how to test such a thing?

[Scott Kiser]

GREAT question.

[august]

Even more so than any performance optimizations, I'd be curious to see how much of a performance differential people will see with the new Raspberry Pi 2 that's been announced. At the very least, it seems to have a usable amount of RAM - so that seems promising.

[drich]

I have had to back-burner my Concerto testing for a while as I'm not going to be using it at work (something about closing our office and laying off 500+ people). I'm still looking at it for a couple of other ideas, but those aren't as pressing.

That said, I do have it running on my pair of Pi systems -- one as the server and one as the client. With the latest raspbian release I was able to get the client running with chromium using the ideas from this blog:

  http://blogs.wcode.org/2013/09/howto-boot-your-raspberry-pi-into-a-fullscreen-browser-kiosk/

I really like the idea of not running lightdm and just using X with chromium running in kiosk mode. Auto-detecting the monitor is great as well and seems to work perfectly in my testing. Not running lightdm brings back memories of the way I used to do things before login managers like xdm and gdm when you had to start X11 from the command line! (yes, I am an old fart :-) ).

 

---
Dan Rich <dr...@employees.org> |   http://www.employees.org/~drich/
                               |  "Step up to red alert!"  "Are you sure, sir?
                               |   It means changing the bulb in the sign..."
                               |          - Red Dwarf (BBC)

[Gent Cav]

I am new to the group, and recently started playing with Concerto for an info channel on our cable TV system using Raspberry Pi and Banana Pi. I appreciate all the work those put into Concerto which made my life easier.

I wanted to let the community know that it also works with Banana Pi even though this is in early stages of development (Banana), my cpu utilization is about 40% compared to 90% on RPI.

One of the things I have discovered with RPI is that all the online instructions for auto starting the browser refers to the wrong directory, those trying to make it work, try this:
(keywords: raspian autostart not working )

In new versions it is not supported in this autostart file

sudo nano /etc/xdg/lxsession/LXDE/autostart

I changed the code to the below autostart file.

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

 

 

 I have used instructions at: http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=94542

Gent

[drich]

Gent,

You might want to take a look at the ideas at:

  http://blogs.wcode.org/2013/09/howto-boot-your-raspberry-pi-into-a-fullscreen-browser-kiosk/

It uses chromium instead of the now long-in-the-tooth midori and is working perfectly for me in my tests. It will also dynamically get the resolution of the monitor and only start up once a monitor is connected.

 

---
Dan Rich <dr...@employees.org> |   http://www.employees.org/~drich/
                               |  "Step up to red alert!"  "Are you sure, sir?
                               |   It means changing the bulb in the sign..."
                               |          - Red Dwarf (BBC)

[Gent Cav]

This is much nicer, I will try this one instead.

I have also experienced some (I assume) bugs. I am listing them here so it can help others or the developers:

I am running Concerto on Debian Wheezy as a virtual server (openvz) in Proxmox with one RaspberryPi and also on BananaPi where I tried both Midori and Chromium as browsers.

In order to delete a content, you need to edit and save first.

If you edit a content, time-end changes to whatever the default is, regardless of what you originally set to.

If you modify the template that is being used, you have to reboot the RPI or the PC you are using to display, otherwise content breaks (majority of the time).

You can not install plugins via web interface (gems). Manual install is needed.

If you have a content is not assigned to a feed, you can not see it to delete/assign etc. PhpMyAdmin is needed in this case.

Once you create a content, other than time and assigned feeds can not be modified thus you need phpmyadmin.

I am also experiencing stuttering on ticker text when it scrolls. It is smooth until a picture or text change happens in one of the content areas. I first thought it was an issue with high cpu usage on RPI but then it also happened on BananaPi where cpu utilization is not as high as RPI. I am not sure if this is due to the marquee applet or the X, cpu, memory, etc. If anybody has any clue, please share.

Gent

[bph...@gmail.com]

Hi everyone,

I've had good experience testing the functionality of the Raspberry Pi 2 B as a client.  While I'm using the standard Raspbian install and using Chromium in kiosk mode, it certainly seems to run smoother using Epiphany.  Has anyone yet figured out a way to boot to Epiphany in full screen?  My second problem is that while Epiphany plays videos fine in full screen, you have to click the play button in the middle of the video for the Youtube videos to play.  Ultimately, I think the RPi 2 should work fine, but the two hurdles are booting full screen to Epiphany and making the videos play when the content comes up.

I've tried to get videos to play using Chromium, but it asks for the Adobe plugin.  And I can't figure out how to install it.

Any thoughts?

Brian

[Scott Kiser]

I've had the same issues with Epiphany and Chromium. If I find a solution I will share it. 

(sent from my mobile phone)

--

[Michael Holt]

Has anyone tried the new Raspberry Pi 2 with concerto?

[Brian Yulke]

I have an RPi2 on order with the intention of testing it out in my environment.  I will happily report back my results, including a brief comparison to my experience with the RPi as a client.

[Michael Holt]

I was actually able to borrow a RPi2 from a friend and got things running on rasbian but it was very slow/laggy and wasn't impressed.

[beid...@gmail.com]

Ok, just my two cents(sense?) worth,

I've been using 3 RPis as Concerto front-ends for over two years now.  We started out on 1.9 and now run 2.2.7.  No issues.  Each RPi runs Raspbian Wheezy with Chromium in kiosk mode.  I did no graphic or performance tweaks to them.  Cron job reboots them once a week. One RPi runs four sections, and the other two run two sections.  Performance in production has been perfectly acceptable. Caveat: I do not run video on any of them as Chromium wont work well with gnash.  I am actually going to be getting 3 RPi2's to work along side the three RPis we already have. Then Ill experiment with Epiphany and video

On Tuesday, December 30, 2014 at 11:20:28 PM UTC-5, august wrote:

[Scott Kiser]

Beidemank, 

I have a feed that embeds HTML5 YouTube videos in iframes with autoplay; Epiphany on the RPi2 is quite capable of playing them, but only manually - you have to click on the video. Autoplay works on other platforms. If you find a workaround for this issue, you'll be my hero! 

(sent from my mobile phone)

--Scott Kiser

Network, Telecom and Systems

Ivy Tech Community College - Northeast

--

[Scott]

On Wednesday, March 11, 2015 at 2:08:39 PM UTC-4, Brian Yulke wrote:

I have an RPi2 on order with the intention of testing it out in my environment.  I will happily report back my results, including a brief comparison to my experience with the RPi as a client. 

On Wednesday, March 11, 2015 at 2:10:56 PM UTC-4, Michael Holt wrote:

I was actually able to borrow a RPi2 from a friend and got things running on rasbian but it was very slow/laggy and wasn't impressed.

 

I've been banging on my RPi2 for the last few days, and performance compared to the original RPi is stellar.  Transitions and video are working and I'm satisfied.  (Except I'm still working on that Epiphany autoplay issue.) 

Compared to a small-form-factor PC, like say virtually any Micro-ATX or Mini-ITX system, it IS slow; but c'mon, it's one-sixth or one-tenth the price! 

[Scott Kiser]

A quick demo - no customization on the Pi, just a straight Raspbian install from scratch. 

https://youtu.be/34bhFGrLaWI

(sent from my mobile phone)

--Scott Kiser

Network, Telecom and Systems

Ivy Tech Community College - Northeast

--

[ma...@campusvision.ca]

Yes, it is possible to boot Epiphany to full screen... and to autoplay the videos.  I have it working nicely with Concerto 2.2 and Raspberry Pi 2.    

From a fresh install of raspian, run:

raspi-config  (enable it to boot to desktop)

sudo apt-get update

sudo apt-get dist-upgrade

sudo apt-get install epiphany-browser unclutter

sudo nano -w  /etc/xdg/lxsession/LXDE-pi/autostart 

Delete all file contents, replace with (where CONCERTO is your server IP and FRONTEND_NUMBER is your concerto screen number):

@xset s off

@xset -dpms

@xset s noblank

@unclutter -idle 0

@/etc/epiphany-fullscreen.sh http://CONCERTO/frontend/FRONTEND_NUMBER

sudo nano -w /etc/epiphany-fullscreen.sh

Insert into file:

#!/bin/bash

epiphany --private-instance $1 &

# Go full screen

sleep 10s

export DISPLAY=:0

WINDOWID=$(xdotool search --class Epiphany | head -1)

xdotool windowactivate --sync $WINDOWID key F11

sudo chmod +x /etc/epiphany-fullscreen.sh

Now the raspberry pi will boot directly to Epiphany, and after about 10 seconds will switch to fullscreen

As for autoplaying videos - as long as you use a video that is NOT hosted on Youtube, it will autoplay.  It will not autoplay Youtube because Epiphany has some special handling for Youtube that specifically disables autoplay.

[ma...@campusvision.ca]

Missed one item.  You will also need to install xdotool:

sudo apt-get install xdotool

[Marco]

Do you install the client or the server?

I have a problem during the installation of concerto (see https://groups.google.com/forum/#!topic/concerto-digital-signage/yyJKrJCVPFg)

Maybe you can help me?

[Michael Holt]

It's not perfect or complete, my plans have put on the side burner for now, but here's the scripts and commands I ran when getting the client installed on a fresh version of rasbian.... I had performance issues that I haven't tracked down yet but should give you a starting point

https://github.com/mholtrlc/Concerto-Raspbian-Player

--
You received this message because you are subscribed to a topic in the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/concerto-digital-signage/6y-Gub2Srus/unsubscribe.
To unsubscribe from this group and all its topics, send an email to concerto-digital-s...@googlegroups.com.

To post to this group, send email to concerto-dig...@googlegroups.com.
Visit this group at http://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

--

Michael Holt / IT Administrator
(661) 705-4711/ mh...@reallifechurch.org

Real Life Church Office: (661) 775-7401 
23841 Newhall Ranch Rd
Valencia, CA 91355
http://www.reallifechurch.org

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

[hgdi...@gmail.com]

I've been running Pi as a display driver for 3 signs in a small business. For anyone considering it, do yourself a favor and get Pi-2. The extra performance is a must.

For the nay-sayers, Pi isn't perfect, agreed. It has many shortcomings.

On the up-side: Most current TVs have a USB port that can source the required 1/2 amp. Use the shortest HDMI cable you can get. Add a decent USB Wi-fi dongle. The TV becomes a fully-standalone signage display. Just follow August's instructions, put it up and plug it in.

One addition I made after learning "the hard way" is to add another cronjob for the Pi user's crontab:
10 * * * * sudo touch \forcefsck

People turn things off at night, and the PI will be "crashed" by power loss. "\forcefsck" causes fsck to run every time the Pi reboots. Since it doesn't get shut down properly, fsck is a good idea and it only takes a few seconds to run during startup. Occasionally the Pi will reboot after fsck, but that means something important was fixed.  Since that simple change, I have not had a call that the display doesn't start in the morning.

No, the Pi won't be able to do HD video with 5.1 surround sound.  But are we talking about a sign or a home theater?  It works fine with slides, text, and even motion GIFs/PNGs. It's great for "suggestive sell / up-sell" ideas. Customers also love a weather map, local forecast, or radar image.

Pi might not run a full kiosk, but as a signage driver it's simple and neat, plug-and-play. It's inexpensive and you don't have to figure out where to put it. Attach it to the bracket behind the TV, and you're up and running.

[tom.n...@adama.com]

I completely agree, and this panel of experts do too. Raspberry Pi is great if you want your presentation to look like a mainframe console or a browser on dial-up network, but if you want to do HTML 5 with animations you have to acquire the correct hardware. Keep your Raspberry Pi in the drawer for IoT experiments.

[mickdu...@gmail.com]

Hi,

I've come back to Concerto and Raspberry Pi after a good few months... I setup my Pi as per these instructions, which is still working, but I now want to revert back and set everything back to manual... but all I'm getting is a black screen with a mouse pointer, how can I get the desktop back?

Thanks,

Mick.

[Marvin Frederickson]

Comment out the last line in the file below and reboot.. this will keep the script that invokes epiphany from launching...

sudo nano -w  /etc/xdg/lxsession/LXDE-pi/autostart 

@xset s off

@xset -dpms

@xset s noblank

@unclutter -idle 0

#@/etc/epiphany-fullscreen.sh http://CONCERTO/frontend/FRONTEND_NUMBER

[mickdu...@gmail.com]

Many thanks Marvin, 

Much appreciated.

Mick.

[aaron....@gmail.com]

I have had good luck using a Pi 2 with chromium as the browser. This has been a great improvement on using epiphany.It has been driving 1920x1080 displays for two months now. I have not tried to push video, but otherwise it has performed well.

[mjo...@cpsctg.org]

I also have had a system set up for almost a month now with almost no issues. Running a Pi2 and epiphany browser setup driving up to an 80 inch TV with no problem. I do beilve that this system is callable of running Picture and Test to the screens with this set up  

[guyhal...@gmail.com]

Also made the transition from a dedicated Windows PC to a Raspberry Pi 2 running Chromium and it's running great.  Transitions look just as good as they did before and we don't use video playback here, so probably going to move forward using them across the enterprise.

A tip for anyone struggling to get a browser to boot using the latest Raspbian following Marvin's instructions - the file you need to edit now is ~/.config/lxsession/LXDE-pi/autostart

Beat my head for awhile trying to get it to work until I found that tidbit.

[Matthew Swanson]

So I think there was an update to iceweasel recently and all my screens are showing a broken page icon when trying to load content. Anyone else have any insight or similar experiences with this?

[Matthew Swanson]

Ok so this issue is more widespread than I thought. It is affecting all the Raspberry pis after the upgrade to 2.3.2 from 2.2.7 and upgrading the frontend to 0.4.0. On many of the feeds, some images will display correctly but others will have a black screen with either a grey broken image icon or grey icon with a triangle, square and circle in it. The issue is presenting itself on both jessie and wheezy builds of raspbian. I would really appreciate any input since this is affecting all of our signs.  

On Thursday, January 7, 2016 at 2:09:54 PM UTC-8, Matthew Swanson wrote:

Upon further inspection it seems it is just 1 feed that is doing this. No idea why.

[Matthew Swanson]

After working through this with Marvin, we determined that one of the images in my feed was way too large for the Pis to handle. It was about 10X larger than 1920x1080. The Pi would keep trying to load it unsuccessfully and that threw everything else off as well. Deleted the content and uploaded it at a smaller res and it worked perfectly.

[be...@shuregroup.com]

Hello August:

I'm planning a small deployment with RasPi2's plugged into HDMI displays.  The Pi's can get power from the TV's USB port.

My concern is what happens if the users power off the TV and cut power to the Pi.

I am already reducing writes to the internal microSD card by reducing logging and moving dynamic data to a USB stick.  

I would love a solution that has a battery, detects loss of line power and shuts the Pi down gracefully.  The standard battery packs that I use for charging my phone or when I can't plug the Pi in don't handle the cutover to line power when the battery gets low.

Thanks,

Bert

[Matthew Swanson]

I'm not affiliated with Concerto but I use many Raspberry Pis at my university with the system. My first concern is having the units not have sufficient power in the first place. Don't these ports on the televisions only provide 0.5-1 amps? It will also probably depend on the TV if powering it off will also cut the usb port power or not. 

You could get a UPS and then write a script to shutdown when it detects the switch, although having a dedicated power supply I think is by far the best option. I also know you can get a power over ethernet connector for your pi so you can power it from your switch...

Cheers

[Scott Kiser]

I've run a v1 model A for days on as little as 230 mA, but we encountered problems trying to run a v2 model B on less than 2 A (amperage as listed on the power supply). 

(sent from my mobile phone)

--Scott Kiser

Network, Telecom and Systems

Ivy Tech Community College - Northeast

--

You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.

To unsubscribe from this group and stop receiving emails from it, send an email to concerto-digital-s...@googlegroups.com.

To post to this group, send email to concerto-dig...@googlegroups.com.

Visit this group at https://groups.google.com/group/concerto-digital-signage.

[Brian Hibdon]

Does anyone lament not having the ability to play youtube videos on the Raspberry Pi?  I admit it's great for everything else, but I do wish I could play the occasional youtube video.  (...unless someone has fixed the web browser to autoplay videos.)

Brian

--
You received this message because you are subscribed to a topic in the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/concerto-digital-signage/6y-Gub2Srus/unsubscribe.
To unsubscribe from this group and all its topics, send an email to concerto-digital-s...@googlegroups.com.

To post to this group, send email to concerto-dig...@googlegroups.com.
Visit this group at https://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

--

Brian

Brian Hibdon

[Scott Kiser]

Collabora's Epiphany plays Youtube videos well enough, but disables autoplay. I would kvetch if someone forked Epiphany to enable autoplay for YouTube. 

(sent from my mobile phone)

--Scott Kiser

[Brian Hibdon]

Any idea why the autoplay feature is disabled?  Seems like that would be a valuable thing.

[August]

For most users, autoplay videos in Flash or HTML5 are incredibly invasive, even with the tab indicators that show that tab is playing audio/video that Firefox uses. On mobile platforms, many vendors disable it completely. While this is incredibly inconvenient when the browser is a signage frontend, it’s probably rather beneficial to users.

-- 
August

[Dan Book]

We are testing some RPi`s 2 B with concerto 2.2.7. We need this server version due to the marquee ticker, which is disabled in newer concerto server version.
The contents of text field, 2x graphics field, date&time and ticker work well. But:

The ticker is still stuttering, especially while another field (text, graphics) changes. The problem is worse when text/graphics changes are soft (slide oder fade). The RPi`s CPU usage is low so it can`t be the problem. 

Any ideas? browser problem (iceweazel)?

[der....@gmail.com]

Hello there,

i want to tell you about my environment, which was working until 2.2.7. The update to 2.3.1 has broken it.
But now, how it was working the last year. I have Concerto Server running on a litte HP N54L Server with Ubuntu Server 14.04 LTS and 3 clients, which are all Raspberry Pies B, the first Generation.
On this clients i have running Screenly OSE, (www.screenlyapp.com/ose/). This is made as a signage-system itself and it's a very easy way for setting up the Raspis and it provides a webinterface for make the configuration on them. There i run the URL of the Frontend from Concerto for 5 minutes and a short video-clip. The Screenly app displays now 5 minutes Concerto-Frontend, Clip 5 minutes Concerto-Frontend, Clip, ...
the clip is because the Raspis were frozen after a while, if i had just the Concerto-Frontend.
Think, this was a good solution, Screenly was my Concerto-Player. :-)
With the new frontend the clients show just a black screen, so that i have to move to a standard raspian with the changes described above, which is working, too.

[Brian Yulke]

I'm curious if anyone has tried Concerto on the new RPi 3.  My understanding is that it is a much faster clock speed, so perhaps it will perform better.

[Sid Hernandez]

I'm also curios about that.

[evi.v...@gmail.com]

The problem with the Pi is not it's clock speed. It's the API into the closed source GPU. Until recently there was no open source driver and thus no acceleration of any browser video or CSS. You could custom develop a video player based on the Broadcom code and OpenMAX but until recently there was no OpenGL which is critical to any cross-platform hardware acceleration.

OpenGL was brought to the platform recently and there are now various stages of experimental support and shims for hardware acceleration of most aspects in Chromium. They are all very experimental and buggy, but if anyone wants to help them out ;-)

[Teemu Lehtilä]

I've done a little bit of testing with Concerto and Rpi v3 and the performance seems to be sufficent. I've also tested with http://wpds.pixelydo.com/ and there is only little hicups with some screen transitions. I've not done any performance related tweaks to the OS and used basic raspbian image. The browser i've used is Iceweasel (renamed firefox). If theres some special tests etc. you would like me to run with it, please let me know and I see what I can do :)

[kab...@gmail.com]

Which script or tools you used on Raspbian to have it as kiosk mode, full screen, no mouse pointer, etc. etc.?

I'm about to begin Concerto deployment here at home, just for testing, with a VM and Raspberry Pi 3 also.

Thanks

[Teemu Lehtilä]

After some testing I changed my setup a little bit and used this excellent guide https://groups.google.com/d/topic/concerto-digital-signage/MiBkD5JOjE4/discussion
Havent disable keyboard shortcuts etc. yet but so far its working great.

[Guy Hale]

I followed the same guide to set up mine. 

However, there is a repo for Chromium now.  I followed this guide here and was able to install (on new screens) and upgrade (on existing screens) the latest version through apt-get: https://www.raspberrypi.org/forums/viewtopic.php?t=121195

On Fri, Jun 10, 2016 at 5:24 AM Teemu Lehtilä <tle...@gmail.com> wrote:

After some testing I changed my setup a little bit and used this excellent guide https://groups.google.com/d/topic/concerto-digital-signage/MiBkD5JOjE4/discussion

Havent disable keyboard shortcuts etc. yet but so far its working great. Also, the command to setup the splashscreen at start doesnt work anymore, probably because debian jessie uses systemd and hadnt had time to solve that yet.

On Friday, 10 June 2016 01:23:52 UTC+3, Enrique Becerra wrote:

Which script or tools you used on Raspbian to have it as kiosk mode, full screen, no mouse pointer, etc. etc.?

I'm about to begin Concerto deployment here at home, just for testing, with a VM and Raspberry Pi 3 also.

Thanks

El miércoles, 25 de mayo de 2016, 10:01:01 (UTC-3), Teemu Lehtilä escribió:

I've done a little bit of testing with Concerto and Rpi v3 and the performance seems to be sufficent. I've also tested with http://wpds.pixelydo.com/ and there is only little hicups with some screen transitions. I've not done any performance related tweaks to the OS and used basic raspbian image. The browser i've used is Iceweasel (renamed firefox). If theres some special tests etc. you would like me to run with it, please let me know and I see what I can do :)

--

[rodrigo....@gmail.com]

Hello RPI friends!  

I was wondering about some stuff concerning the transitions in Concerto, I need some help with this . . . thanks!

How can i change the ads transitions settings at Concerto? Or better in my case, how can I disable transitions? With “transitions” i mean the fade out effects happening in between the ads/announcements displaying? The thing is that those fade outs are working a bit slowish at the RPI when showing the ads, even when i allocated 512 MB minne to the GPU (raspi-config) those are not coming through so well. The other thing is that the ads are not so truthful as to the time in seconds that it's suppose to be showing the ads as config under the www admin dashboard.

Sometimes, when showing an ad, a transition suddenly occurs but just half the time in seconds have past than it suppose to show the ad in seconds, and then, after the transition pass, the browser is showing the same ads than before the transition, and not the ad that suppose to come after, i'm not sure if this delay and stuff is because of the slow transitions, that maybe it feels a bit heavy for the RPI hardware to deliver or if it is because of something else! I wanna to be able to disable the transitions and see if that make some difference with the performance when the displaying of the ads. I am currently using a RPI 3. Should I change the "GL Driver" under "raspi-config"? don't misunderstand me, I really like Concerto server and the Pi, but just feels like I do need know and experiment some more with the optimization, so I thank you again for all support with this matter! 

So, I wonder

- Can i disable the concerto transitions and where can I change those settings?

- Can I change the speed of the transitions occurring?

- Can I change the transitions to another "transition theme"?

regards,

Vangelius

[Omri Asta]

The transition settings are on the screens tab for concerto, select the screen and when you hover over the screen section you will see the feeds you selected and right below it are the feed settings. Fade is set as default and if you are using the pi, TR changing to replace.

On Sun, Mar 5, 2017, 3:48 AM <rodrigo....@gmail.com> wrote:

[rodrigo....@gmail.com]

Hi, Thank you very much Omri Asta, "replace" was what I was looking for! Now it's great!

A little explanation: In Concerto with the Raspberry Pi, the default Fields are "fade-in-animation" and "fade-out-animation" but they don't work well with the Ads displaying, they are a bit too slowish. instead "replace" works like a charm! Thank you!

Regards,

vangelius

[meidam...@gmail.com]

Hi, 

did you manage to get it to run with chromium in fullscreen with opengl enabled? It kept randomly crashing on my rpi3 (current raspian install) until i disabled gpu hardware acceleration via raspi-config. It ran fine in a window, but would randomly hang in fullscreen, sometimes imideatly after switching to fullscreen.

Greetings,

Michael

Am Donnerstag, 16. Juni 2016 20:52:58 UTC+2 schrieb Guy Hale:

I followed the same guide to set up mine. 

However, there is a repo for Chromium now.  I followed this guide here and was able to install (on new screens) and upgrade (on existing screens) the latest version through apt-get: https://www.raspberrypi.org/forums/viewtopic.php?t=121195

On Fri, Jun 10, 2016 at 5:24 AM Teemu Lehtilä <tle...@gmail.com> wrote:

After some testing I changed my setup a little bit and used this excellent guide https://groups.google.com/d/topic/concerto-digital-signage/MiBkD5JOjE4/discussion
Havent disable keyboard shortcuts etc. yet but so far its working great. Also, the command to setup the splashscreen at start doesnt work anymore, probably because debian jessie uses systemd and hadnt had time to solve that yet.

On Friday, 10 June 2016 01:23:52 UTC+3, Enrique Becerra wrote:

Which script or tools you used on Raspbian to have it as kiosk mode, full screen, no mouse pointer, etc. etc.?

I'm about to begin Concerto deployment here at home, just for testing, with a VM and Raspberry Pi 3 also.

Thanks

El miércoles, 25 de mayo de 2016, 10:01:01 (UTC-3), Teemu Lehtilä escribió:

I've done a little bit of testing with Concerto and Rpi v3 and the performance seems to be sufficent. I've also tested with http://wpds.pixelydo.com/ and there is only little hicups with some screen transitions. I've not done any performance related tweaks to the OS and used basic raspbian image. The browser i've used is Iceweasel (renamed firefox). If theres some special tests etc. you would like me to run with it, please let me know and I see what I can do :)

--
You received this message because you are subscribed to a topic in the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/concerto-digital-signage/6y-Gub2Srus/unsubscribe.

To unsubscribe from this group and all its topics, send an email to concerto-digital-signage+unsub...@googlegroups.com.

[Omri Asta]

I'm running it on the first model B...it is running in chromium

To unsubscribe from this group and all its topics, send an email to concerto-digital-signage+unsubscr...@googlegroups.com.

To post to this group, send email to concerto-dig...@googlegroups.com.
Visit this group at https://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/concerto-digital-signage/6y-Gub2Srus/unsubscribe.
To unsubscribe from this group and all its topics, send an email to concerto-digital-signage+unsub...@googlegroups.com.

To post to this group, send email to concerto-digital-signage@googlegroups.com.

Visit this group at https://groups.google.com/group/concerto-digital-signage.
For more options, visit https://groups.google.com/d/optout.

--

Omri Asta

[rodrigo....@gmail.com]

Hi Michael, 

WORKAROUND:

if your RPI is crashing you could put -as a workaround- a restart crontab every each hour or avery 2 hour?

Trade secret - HOT TIP:

I am using Screenly player as THE Concerto player, works better than any web browser right now.

Greetings!

Vangelius

[Baylink]

On Monday, December 11, 2017 at 6:20:54 AM UTC-5, rodrigo....@gmail.com wrote:

Trade secret - HOT TIP:

I am using Screenly player as THE Concerto player, works better than any web browser right now.

Could you expand a little bit on how you set that up?

[Rodrigo Vangelius]

Hi, i'm using Screenly for showing images in HD size resolution, i just use the Concerto link and paste it in the Screenly URL part of the publishing Screenly webpage, then the adds are showing without problem. I am not using Concerto Weather or RSS or Showing The concerto Time/Clock and stuff, I just use Simplicity in Concerto with a full screen picture coming from the Concerto Server and publishing through Screenly in a Raspberry Pi.

Greetings!

Vangelius

--

You received this message because you are subscribed to a topic in the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/concerto-digital-signage/6y-Gub2Srus/unsubscribe.
To unsubscribe from this group and all its topics, send an email to concerto-digital-signage+unsub...@googlegroups.com.

To post to this group, send email to concerto-digital-signage@googlegroups.com.

[Baylink]

So I've (finally) gotten a couple of Rpi3B's deployed this past weekend, using the excellent writeup buried somewhere in this thread that the DejaGoo UI simply *will not* let me find right now.

And so far, things are going well.

I did an apt update, upgrade pass before launching and coupling chromium to the server, and al the other steps to hide cursors and panels and boot (oh my)...

I don't seem to quite be hiding the entire boot sequence, but I'm not as concerned about that as I might need to be elsewhere.

I haven't tested stored video, or live video or Youtube yet; those are on this week's agenda.

So as of Summer '18, I think using an RPi -- model 3 -- as a client machine is less ridiculous an idea than it used to look like.  More -- as the late, great Jerry P used to say -- when I know more.

[Baylink]

So the people at Chromium keep breaking the command line switches that make the browser easy to use in an unattended kiosk environment ... such as the one we care about.

There *used to be* (cause it's mentioned in this thread) a switch that told Chromium not to display the "Reopen your tabs" dialog after a crash.  But, like a number of other switches, it broke in successive releases of Chromium, and despite open bugs, no one's bothered to fix it.

There *is*, it turns out, a reliable way to solve this problem.

Hints on it are in this posting -- I can't guarantee that the config file will be in exactly the place this article suggests, but it shouldn't be too hard to find.  And you can either make a safety copy of that Default file or just 'chatter +i' it before you start the browser; both should work.

[pleti...@gmail.com]

Hello,

this article says that Raspberry Pi is not suitable for the the Concerto Signage player. This article was created in 2014 when only Rapsberry Pi first edition was introduced. But what about RPi 2, RPi 3 or even RPi4? Are they still to slow for being used as the Concerto signage player? The article is pinned so it should be valid and updated for everyone who read it.

Thank you

[Andrew Potts]

You can run Chromium Browser in kiosk mode without any problems.

I've got some Pi 2 and 3's out there... The stream live news from YouTube without issue or lag... Just waiting to get my hands on a 4 with 2gb ram

--

You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.

To unsubscribe from this group and stop receiving emails from it, send an email to concerto-digital-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/concerto-digital-signage/669cef25-9348-41a2-8e9d-c0820fbc3486%40googlegroups.com.

[guy...@gmail.com]

Works fine for me.  I use mostly RPi 3s but now I have a few 4s going as well.  RPi 2's tended to crash after about a week or two, sooner if videos were in a feed, so I retired them.  I use Chromium in kiosk mode, works great.  

-Guy