Admin housekeeping

[Mike Triassi]

The concerto server has been very stable. It ran 58 straight days
until I shut it down and has been running 13 days since. No server
issues. Still, I need to know how to maintain this system so I
thought I would post a couple of questions.

Backup Tools
I am using Webmin which has a "Backup Configuration" function. My
first thought was to use this to backup all the modules but wanted to
see if the Concerto team has a recommended or convenient backup
strategy or tools. Let me know.

1) Purging Content
Will Concerto automatically remove expired content or does this have
to be done manually?

2) Admin Utilities
There are some buttons on this page that look useful but come with a
warning to be used wisely. What are good uses for Masquerade, Page
Load Statistics, and Reset Session.

3) Screen Durations
It seems that data changes are noticed on the next screen update but
changes to the duration do not have a real-time impact. Is there a
way to have these changes recognized.

4) Troubleshooting Scripts
I used a couple of scripts during development
/scripts/cron.php" to troubleshoot my RSS feeds.
/install/diagnostics.php/test to verify the server install
Any other tips/tricks to monitor performance etc.

Thanks
Miks

[Mike Triassi]

oops Backup Tools should have been question 1. sorry for any
confusion.

[Brian Michalski]

I'll try and go down the list:
1. We don't have any built-in backup function, but all the important
stuff to Concerto is in the root Concerto directory (like
/var/www/concerto) plus the Concerto database. A poor mans backup
might copy the directory once every few days and take a mysqldump. I
also do this every time I'm about to upgrade, just in case something
goes wrong.

2. Concerto doesn't have any bulk delete or purge function. We've
never wanted to delete expired content, but if you want to you could
script the use of a Content objects delete (maybe destroy?) method
which will remove any files, delete the entry in the Content table and
the feed_contents table.

3. Page load statistics is a tool we use to time how long certain
pieces of PHP code take while loading the page. It can help
troubleshoot if a view or controller is running too slow. Masquerade
let's you jump into someone else's shoes, though Mike D has told me it
might have a bug in the no-CAS branch. Essentially we use it to login
as other, non admins, to help trouble shoot permission problems or
user (PEBKAC) problems. Reset session can clear out any strange
session information, it's probably an artifact from development when
we were building the framework and authentication pieces.

4. I'm not super clear on what you're asking. A content's duration
should be updated by a screen everytime that content is shown (no
client side caching). I believe the screen's power on/off times are
polled every few minutes.

5. We try and squeeze every drop of performance out of Concerto with
APC and Memcache. On our production server the code never changes
automatically, and APC let's us cache a compiled form of the code so
PHP doesn't always have to access the file. Some "recent" commits
have helped reduce the code's cache size, it's only a few megabytes
max. Memcache is used to cache resized images. You can enable it in
config.inc.php and it will start filling up with resized images. This
works really well if you have lots of clients accessing images that
haven't been client-side cached (like screensavers, web widgets, etc).
You can't use memcache if you do any backend tricks to update images
because the cache can't easily be expired for those images, but it
works great in the simple scenarios. Both APC and Memcache are set it
and forget it tools that make things run faster.

~Brian M

> --
> You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.
> To post to this group, send email to concerto-dig...@googlegroups.com.
> To unsubscribe from this group, send email to concerto-digital-s...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/concerto-digital-signage?hl=en.
>

[Mike Triassi]

thanks!

> > For more options, visit this group athttp://groups.google.com/group/concerto-digital-signage?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Mike Triassi]

On the duration issue. I had made changes to the SQL database and
did not see a change to the duration. Content changes to happen.

On Jul 8, 9:23 pm, Brian Michalski <bmichal...@gmail.com> wrote:

[Brian Michalski]

Which table are you editing the duration in?  The duration that matters is in the feed_content table, not the content table.

~Brian M

On Thu, Nov 29, 2012 at 11:26 AM, PKBellamy <peter.k...@gmail.com> wrote:

Mike & Brian:

I've noticed this same behavior and I've just started trolling through the forum for ideas (hints, hacks, etc).

For instance, I can enter ticker text via the web gui, then use MySQL to directly change the content type from "text/plain" to "text/html" and then change the content itself to include specific markup for special formatting, etc. And these change are reflected immediately on the screens.

However, when I use MySQL to try and change the duration from say '5000' to '7000', this has no immediate or apparent effect.

I discovered that restarting the web-browsers on the screens was enough to cause the new durations to kick in, but can this be done without that level of manual client/screen manipulation?

I've found the DEFAULT_DURATION setting in the config.inc.php file, but I'm not looking to change ALL durations, just a few specifically after-the-fact.

What's the secret?

Thanks.

-pkb

> > To unsubscribe from this group, send email to concerto-digital-signage+unsub...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/concerto-digital-signage?hl=en.- Hide quoted text -
>
> - Show quoted text -

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/concerto-digital-signage/-/j_tvvdUoMzsJ.

[Brian Michalski]

The purpose was that we forgot that a feed moderator might want to override the duration after content was uploaded.  If my memory is right, we got a handful of content submitted with very long durations (like 90 seconds for a short ticker) and quickly moved duration to the feed_content table so it could be overriden on a per-feed basis during moderation.

We're carrying this philosophy over to V2, using content.duration to store the requested / uploaded duration and the submission.duration to store what was approved / in use on feeds.

I recall forgetting about this a few times myself... glad to help!

~Brian M

On Thu, Nov 29, 2012 at 2:05 PM, PKBellamy <peter.k...@gmail.com> wrote:

Doh. That would explain it.

So out of curiosity, what purpose does the 'duration' field in the content table serve?

And many thanks for the hard work and dedication to this project!

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/concerto-digital-signage/-/pV8QYr7WI0cJ.