Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mkbrown69

Pages: 1 ... 9 10 [11] 12 13 ... 15
Users / Re: Cameras, Motion, and notifications
« on: May 07, 2012, 03:47:36 am »

Did you get anywhere with this? I've been planning to head down the same route... experimenting with using my IP camera to generate events based on motion detection. Also still struggling a bit searching the wiki and forums to see if there is a "standard" way to do it.



You can generate e-mail alerts using the respond to events Wizard.  The basic gist of it is:

A sensor is tripped, what device equals your camera, when = Day, Night, or blank, What trigger state = tripped = 1.

You can then add commands using the advanced wizard.

Pick the General info Plugin on the core, and choose event Send Email.  Fill in the blanks as listed.  That will just send you an e-mail; no pictures attached.  Presuming you're on 10.04, you'll need the package 'heirloom-mailx' installed; that is the mailx that modern Ubuntu's are using now.  The Mailx template listed in the Wiki is no longer necessary, and probably should be removed from the wiki to prevent confusion.

It would be cool if the General Info plugin Send email function was extended to support directly adding attachments, and for allowing a script to be run which is then piped into the mailx command for e-mailing.  The security plugin might need to be extended to transfer/transmit security and sensor data to the Send E-mail function.  Just thoughts... I'm not volunteering you for anything  ;)

I'm looking at Kmotion2, but starting to think that integrating it might not be the best idea.  It may be better to figure out how the masks and other advanced functionality is done, and add that directly into LMCE Web-Admin pages.  Give me a couple of months to figure this out; I'll likely post interim measures along the way.  I've done some PHP scripting in the past and fairly recently, so I'm a less intimidated by that than by C++ code.

Hope that helps!


P.S.  I found some folks who have configured their (non-LMCE) motion.conf  to send e-mails with picture attachements.

on_picture_save mailx -s “Test mail” -a %f

Users / Re: Cameras, Motion, and notifications
« on: May 07, 2012, 03:22:02 am »
Question to anyone presently using the Cameras functionality.  How do you presently access or view the stored camera footage?  I don't see anywhere to view the stored events/alerts in the Roaming Orb Orbiter, I only see it in the LMCE Web Admin (Security -> Alerts Log).  Am I correct in assuming that this functionality is presently limited to the WebAdmin only (meaning not present in MD Orbiters)?

Thanks for your time!


Users / Re: Is it supposed to behave like this?
« on: May 04, 2012, 05:53:57 pm »

The problem is more that RoamingOrb (or the Dianemo iOS app) displays nothing at all; they won't load any screens if a "modal" type dialog is on the regular orbiters.  You launch the app and it spins away doing nothing.  Attempting to log into the web orbiter does the same thing; there is no orbiter UI.  This could lead the user to believe that the "system" is broken if they don't have a regular orbiter to see the message on.  There might be a reason for this behaviour, in which case something should be done on the WebOrbiter or WebAdmin to allow the user to understand that their input/action is required.  If there isn't a reason for this behaviour, then I guess a bug would need to be filed.

Don't know for sure, but it might relate to an existing bug:

My concern is for the End-user experience for those who might have a core, uPnP boxes only for media, and iDevices for controlling it, which could be a use-case for people just getting into LMCE with entry level or existing hardware.

Thanks for your time!


Users / Re: Cameras, Motion, and notifications
« on: May 04, 2012, 05:01:36 pm »

Cool!  Thanks!  Being a SysAdmin type, my strengths are more in the system and infrastructure layers, so I'll look at getting Kmotion2 and motion playing nicely together.  We'll definitely trade notes...

Thanks for the assist!


Users / Re: Cameras, Motion, and notifications
« on: May 04, 2012, 03:25:13 pm »

I've installed Kmotion2, but haven't got it all working yet.  I haven't had a lot of free time to investigate, as I'm doing a college zOS course on the side, and it's chewed up way more time than I'd anticipated.

I'm still trying to figure out how to integrate it cleanly, so that MotionWrapper and Kmotion2 don't fight over control of the cameras or events.  Kmotion2 expects to do the camera configuration and management, and it's not managed the same as the underlying motion on the system.  Plus I'll have to figure out how some of the LMCE infrastructure works, so it would all work "automagically"... so, I've got a bit of a learning curve ahead of me.  I might also look at ZoneMinder as an alternative front-end and for events, just to compare/contrast functionality, capabilities and possible integrations.  (I've rolled out ZoneMinder in the past).

The ironic thing is that I first started looking at LMCE as a means to reduce the level of effort required to maintain my own "home-rolled" infrastructure... ;)

Sorry I can't be of more help than that!


Users / Is it supposed to behave like this?
« on: May 04, 2012, 03:14:49 pm »
Morning folks!

I've been playing around with LMCE 10.04 in a test environment for a while now.  I'm mostly using iDevices and RoamingOrb to access it, and I've noticed that if the core has detected a NAS or something like that which causes a message to appear on the Orbiters asking the user to do something about it, the Proxy/Web Orbiters that RoamingOrb depend on are blocked and become un-responsive.  The web orbiter is also similarly blank.  Is it supposed to behave that way?  Could something be done to prevent the RoamingOrb orbiters from being blocked?  I'm thinking of the use case where someone might only have iDevices and uPnP boxes, and a blocking event might cause the (non-technical) user to think the system was broken or locked up.

Thanks for your time!


I would think that Myth 0.25 is going to be a huge improvement over 0.23 in terms of integration.  It really looks like the Myth devs have put some thought into how it integrates into other things.  The services API exposes a lot of the set-up and operational aspects of MythTV to external control, which in theory could be put into the LMCE Myth plugin.  Similarly, the Myth System Events could be used to send DCE messages to indicate to the DCErouter (and the rest of the LMCE system) what Myth is doing.

The Capture service is a series of APIs related to the capturing of recorded content. It includes methods of settings up capture devices, card inputs, and may also be expanded in the future to more directly control those interfaces.

The Channel service is a collection of methods for editing channels, adding channels, deleting channels, and modifying lineups and XMLTV services.

The Content services provides a means of serving video, music, and image content from your MythTV system's collection. Images can be dynamically scaled and served by the backend according to your request.

The DVR service allows the programmer to interface with recorded metadata in a variety of ways.

The Frontend service is actually run on Frontend systems (default port: 6547) and allows query of location, playback status, sending remote control messages, and sending popup messages, among other tasks.

The Guide service is a group of methods for accessing the program guide information for use in scheduling, and guide grid applications.

The Myth service is dedicated to MythTV specific settings, and is a series of utility APIs for influencing the way MythTV works on a low level including Storage Group configuration, settings modification and query, hardware profiling, and database backup and repair.

The Video service is used to query and modify video metadata, look up metadata, add new videos to the library, and other video-library-specific functionality.

    * Recording pending
    * Recording started
    * Recording finished
    * Recording deleted
    * Recording expired
    * LiveTV started
    * Playback started
    * Playback stopped
    * Playback paused
    * Playback unpaused
    * Playback program changed
    * Master backend started
    * Master backend shutdown
    * Client connected to master backend
    * Client disconnected from master backend
    * Slave backend connected to master
    * Slave backend disconnected from master
    * Network Control client connected
    * Network Control client disconnected
    * mythfilldatabase ran
    * Scheduler ran
    * Settings cache cleared

I've un-installed the MythTV plugins from my test LMCE system, and am looking at getting Myth 0.25 running and stable from the infrastructure point of view on my 10.04 LMCE test system.  I'm a SysAdmin, not a programmer, so the LMCE Plugins are beyond my ability and available time for the foreseeable future.  If a real programmer wants to take a crack at the plugins, I'm more than willing to help at the infrastructure layer and with testing  (although it'll have to be in a couple of weeks; my z/OS final exams are coming up soon!).

BTW, 12.04 will bring other complexities with it due to the re-basing of the kernel, drivers and utilities, and user-land, so it may be better to make the new Myth (and other major infrastructure changes like qOrbiter) work on 10.04 first, and then port forward to 12.04.

Hope that helps!


I'm not using LMCE in production right now; I'm testing it and playing with some proof-of-concept ideas that I'll throw forward for inclusion when I get them usable.

I am running a production MythTV 0.24 environment, with a master back-end, a slave back-end/front-end, and three other front-ends.  The Slave and the front-ends all run MiniMyth.  I'll likely be upgrading them to 0.25 when Debian-Multimedia has it in stable.  I've run Myth since 0.21 (with Freevo for three years before that), and it's been generally stable and the WAF/KAF has been high.  The Myth stats page shows 4050 episodes recorded over the last three years, with a mixture of Analog cable, Digital OTA, and a Digital cable box (6 tuners in total).

Myth and VDR both exist in LMCE now for a reason.  Some of those reasons may be technical, some may be historical.  Out of curiosity, I'd posted a poll asking what people were using.  76% of the people who had responded indicated they were using Myth.  I believe Dianemo has moved to using primarily MythTV (Dianemo users are welcome to correct me if I'm mistaken).  It would be interesting to see a technical comparison between the two, and see where the strengths and weaknesses are between the two, and how well each can/do integrate into the LMCE system.  That kind of capability and requirements analysis could help drive decisions around architecture and features.  It doesn't necessarily mean that the less capable is removed; if the devs wish to support both, it could be used as a tool to drive innovation to address the deficiencies.  It could also determine where to best spend limited amounts of developer time if there's a huge gap in capabilities.

As best as I can see, VDR basically supports DVB and MPEG encoder cards, plus some European IPTV providers (again, correct me if I'm wrong).  MythTV supports those plus the HDHomeRun series, the Ceton cards, ATSC tuner cards, and the HDPVR.  So, where a user lives, what their input sources are, and what hardware they have access to will drive the choice of VDR vs MythTV.  At the very least, quantifying some of that could be useful in setting AVwizard defaults, and building documentation in the Wiki.

My $0.02 worth before HST...



Just as a point of interest, Robert McNamara of the Torc project ( - a fork of MythTV) has submitted for App store approval an iOS Universal app which leverages the 0.25 Services API to create a remote control and stream/viewing application for iPads/iPhones/iPods.  It's a native iOS app, and all it's functionality is via the Services API.

That could bode well for a stable interface for LMCE into Myth for all aspects of control.

Just thought I'd pass that along...


Users / Re: MD idle shutdown?
« on: April 24, 2012, 04:52:31 am »

Thanks for the pointer.  I'm not looking for that so much as for the usual kids leaving it on, or the auto-wake when the router reloads.

I'm using MiniMyth right now, and use a script to shutdown a slave backend when it's sitting on the MythWelcome screen.  I'd planned to expand it to look at how long the screensaver was running for, but haven't gotten around to it yet.

For anyone who's interested, here's the script...

Code: [Select]
# Script to safely shutdown slave backend
# Minimum uptime in minutes to avoid shutting down prematurely.
#SHUTDOWNCMD="su -c /usr/bin/mm_sleep root"


UPTIME=`uptime |cut -f4 -d" "`
UPTIME_UNITS=`uptime |cut -f5 -d" " |tr -d ','`

echo "Uptime:" $UPTIME $UPTIME_UNITS

if [[ $UPTIME_UNITS == "min" ]] && [[ $UPTIME -lt $MIN_UPTIME ]]
echo "Uptime less than minimum uptime:" $MIN_UPTIME
exit 1

# Check if mythfrontend is running, exit if true
if ps -C mythfrontend | grep mythfrontend -c
echo "Mythfrontend running, shutdown aborted"
exit 1

mythshutdown -s

echo "MythStatus code:" $STATUS
#   0 - Idle
#                         1 - Transcoding
#                         2 - Commercial Flagging
#                         4 - Grabbing EPG data
#                         8 - Recording - only valid if flag is 1
#                        16 - Locked
#                        32 - Jobs running or pending
#                        64 - In a daily wakeup/shutdown period
#                       128 - Less than 15 minutes to next wakeup period
#                       255 - Setup is running

case "$STATUS" in

echo "Myth is idle, shutting down now"
mythshutdown --setscheduledwakeup
        su -c 'rm /etc/rc.d/rc/K60modules_automatic' root
        mm_service backend stop

        echo "Myth is busy recording"
        exit 1

        echo "Myth is locked, aborting shutdown"
        exit 1

        echo "Jobs running"
        # Check if mythcommflag is running locally, exit if true
        if ps -C mythcommflag | grep mythcommflag -c
                echo "Mythcommflag running, shutdown aborted"
                exit 1
        # Check if mythtranscode is running locally, exit if true
        if ps -C mythtranscode | grep mythtranscode -c
                echo "Mythtranscode running, shutdown aborted"
                exit 1
        # This backend isn't busy with jobs, so shutdown
        echo "This backend is idle, shutting down now"
        mythshutdown --setscheduledwakeup
        su -c 'rm /etc/rc.d/rc/K60modules_automatic' root
        mm_service backend stop


        echo "Awake on purpose"
        exit 1

        echo "Busy with unknown tasks, presume this backend is busy"
        exit 1

Hope that helps fuel someone's creativity should they get around to this before I do (which is more than likely as my course runs till mid May)


Users / Re: MD idle shutdown?
« on: April 23, 2012, 03:52:31 pm »
Thanks for the pointers, guys!

I'll dig into it a bit further when I get a bit of free time.  I'll probably post a bash script I use in Minimyth to shutdown a slave backend, so if someone else decides to pursue this as well, they can take some of those factors into account (i.e. don't shutdown if recording/transcoding/commflagging, etc).

Thanks again!


Users / MD idle shutdown?
« on: April 21, 2012, 01:28:00 am »
Good day folks!

I've noticed that when the core restarts, it wakes up the MD's.  Given that they stay running, I'm presuming that there isn't an idle shutdown/sleep function, correct?  I'm just trying to confirm that it doesn't have an idle shutdown;  if it does exist, then I'll have to figure out why it's not working...

I'm running 10.04.

Thanks for your time!


Users / Re: Mythtv and HD-PVR control of cable box.
« on: April 09, 2012, 04:39:06 am »

There's a firmware issue on current versions of firmware for Linux.  The fix will end up in up in a 3.3 Kernel.  Take a good read of <>.

Note this part in particular:

 Note: 29-Aug-2011: The latest version of the firmware, 1.6.29207, dated July 27, 2011, causes oversaturation and color issues with the encoding of the analog signal. Until this is resolved, you do not want to upgrade to this version. Version 1.5.7, from June 17, 2010 appears to work. Hauppauge has acknowledged the issue and provided a link to the earlier firmware for non-Windows systems on their support page: Hauppauge HD-PVR support
A patch has been submitted upstream to fix this issue and it has been merged into Linux kernel v3.3-rc5.

This appears to be the fix:

Until a patch that sets the new defaults is committed to the kernel, you can use v4l2-ctl --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40 --set-ctrl sharpness=0x80 to set the proper defaults.

You might be able to put that into a channel change script.

Hope that helps!



Assuming you want the core to manage QoS or traffic shaping, this might get you started.  You could always google for more specific examples related to SIP & VOIP or RTP/RTSP protocols.



Users / Re: A Split
« on: April 03, 2012, 06:50:04 pm »
hopefully, you verify your numbers in your day job better than you do in this forum... SCNR

We do not have a stable 804 release, but a stable 810 :P

Mea Culpa!  Thanks, I normally do my due diligence at work.  I was posting in the short amount of free time I had before bed, after doing a long z/OS system messages lab after a long day at work, so I'll put it down to having '04' on the <somewhat fried> brain.



Pages: 1 ... 9 10 [11] 12 13 ... 15