HdmiCec: wakeup on 'activity' should ignore standby command

Signed-off-by: pieterg <pieterg@users.sourceforge.net>
HdmiCec: add wakeup on 'TV physical address report' option

Signed-off-by: pieterg <pieterg@users.sourceforge.net>
MovieSelection: Simplify playlist handling

It looks like a list, so use a list instead of a new class.

Make MovieList behave like a list, so you can iterate through it instead
of having to use a loop counter and getItem.

A few minor cleanups too.

I don't like the global "playlist", but didn't quickly see a way around
it.
frontend: get rid of duplicate frontendinfo enums

use iFrontendInformation_ENUMS instead of iDVBFrontend_ENUMS
as readFrontendData argument

Duplicating things, especially enums, is a bad idea.
Both enums were supposed to stay in sync in some magical way.
eDVBFrontend::getFrontendStatus: reduce the number of syscalls

Several status fields are calculated from the same information;
- lockState and syncState
- signalQuality and signalQualityDb
We only need to retrieve this information once.
frontend: do not attempt to read tuner status while tuning

tuner status is not valid, all that matters while tuning
is the 'locked' status
PliExtrainfo: don't update FEdata on iPlayableService.evUpdatedInfo

don't update FEdata on multiple sequential self.CHANGED_SPECIFIC changed() events
servicedvb: add new event evNewProgramInfo

cosmetic: clean up whitespaces
PliExtraInfo: use evNewProgramInfo to determine when to read FEdata ( we can asume zap is finalized on this event )

Put caid/crypto stuff in a lookup table

CurrentService: connect evNewProgramInfo to serviceEvent
MovieList: Autotagger collects sentence parts

Given the following set of recordings:
 Conan the Barbarian 1
 Conan the Barbarian 2
 Merlin the Great
The tag list will now display "Conan the Barbarian" instead of "Conan Barbarian"
true item's number in movielist

Signed-off-by: Mike Looijmans <milo-software@users.sourceforge.net>
cahandler: cache PMT sections

Allows us to distribute capmt before the pmt
sectionreader has produced a result.

TODO: manage the cache a bit more intelligently

Cache is currently cleared when all services have been
unregistered (e.g. when the receiver is put to standby,
and there are no active recordings).
Untill that happens, PMT for each scrambled service
is added to the cache.
PMT sections are are usually less than 200 bytes, so
we should not worry about memory consumtion too much.
servicedvb: fix audio pid cache entry

When we have only one audio stream, we can safely overwrite
the audio pid cache, without risking to remove any
user preference.
Often, the audio stream type might be unknown, or stored
into the cache incorrectly (while scanning).

This modification gives us the chance to fix the audio
stream cache information when there is a single stream.
(if there are multiple audio streams, the user will
cause the cache to be fixed when selecting an audio
stream from the audio selection list)
fastscan: do not store the default audio pid in the cache

It makes no sense to store the audio pid without knowing
the correct stream type.
In fact, storing the pid with the wrong type will make things
worse, because the cache might no be corrected untill the user
selects a different audio track.
InputDeviceSetup: add option to select what type of remote control to use ( on supported platforms only )
Add summary description to setup screen

this to clarify in more text what a specific config setting does mean
currently I did only (most) of the standard configs available in setup.xml

In a skin a summary widget should be used to add the summary see the
example in the PLi-HD skin:

<widget name="summary" position="85,360" size="417,200" font="Regular;20" valign="top" />

This idea is based on a feature by the by Andyblac from the ViX team.
cahandler: fix pmtCache refcounting

store a reference to the original eTable<ProgramMapSection> object
cahandler: do not clear pmtCache while we have 500 entries or less
Setup.py: Fix GSOD at least for timezone setup

By mistake I deleted one row to much
cahandler: compare pmt crc to decide whether an update is required

The version field is only 5 bits, so when we have an equal version,
we cannot be sure the pmt has not changed since we cached it.
So we include the crc of the first pmt section in the check.