Remove doRenumber
Revert "servicemp3.cpp disable buffer for file://"

This reverts commit e349c4ecd0d54196b6628037848d469e3a2deaed.
[display] update prev.png vfd255
update default sat list händling only install then tar file exist and no lamedb exist to prevent overwrite user settings
frontend.cpp: Use old code detection when DTV_ENUM_DELSYS ioctl fails

Using the latest linux-libc-headers the DTV_ENUM_DELSYS is defined
so it fails to properly identify supportsDeliverySystem.

Instead check if DTV_ENUM_DELSYS ioctl returns Invalid Argument (EINVAL)
and use old code detection.

Also print a debug message when unknown error occurs.

Signed-off-by: Erik Slagter <erik@openpli.org>
enigma.cpp: print DVB_API_VERSION and DVB_API_VERSION_MINOR when enigma starts

Signed-off-by: Erik Slagter <erik@openpli.org>
Try to solve an anomaly with the channelselector

E.g. with this scenario:

1. open channel list ( is displayed service from bouquer "A")
2. pres Radio
3. pres TV
4. next Bouquet with Bouq+  (services of bouquet "B")
5. exit

http://forums.openpli.org/topic/35348-epgrefresh-plugin/

Signed-off-by: littlesat <littlesat99@yahoo.com>
dvb: use runtime DVB_API_VERSION check

we cannot rely on a compiletime check, because
the linux-libc-headers we're building against
might differ from the actual kernel headers.
So first do a compiletime check for the availability
of defines and enums (in linux-libc-headers),
followed by a runtime check for the actual kernel
support (where applicable).
replace degree code with char, join import line

Signed-off-by: Erik Slagter <erik@openpli.org>
base/filepush.cpp: Stop background thread in eFilePushThread destructor

The eThread class has a design fault: Classes are supposed to inherit
from it. This can't work in C++, because once the eThread d'tor fires,
the object has alread been demoted and partially destroyed. This
results in the thread now running with halfway destroyed data.

A workaround is to always join the thread in each class that inherits
from eThread, which is what this commit implements.

A proper fix would be to remove all virtual methods from eThread, and
use a "runnable" or similarly named member to actually implement the
thread's code.
eFixedMessagePump: Remove unused start/stop methods

No one ever calls start or stop on it, so remove these.
Since it calls "start()" manually, pass "false" for the "startnow"
parameter of the eSocketNotifier constructor.
ebase.cpp: Cosmetic, add a newline in constructor
filepush: Get rid of eThread::sync

The sync call is way to complicated for what it is used for here. All the
client wants to know is "did I start yet?" which it can easier tell by
looking at its own "m_stop" value.

The intention here is to get rid of the eThread::sync method alltogether.
lib/base/message.h: Use eventfd instead of a pipe

An eventfd uses much less resources than a pipe. A pipe allocates a
~64k buffer and two filehandles. An eventfd is only an uint64 in the
kernel.
filepush.cpp: Fix "kill" arguments

eThread::kill takes a boolean argument, which defaults to "false".
Don't supply a "0", just use the default so we can remove it.
epgcache: Remove eTread::sync usage

All it wants to know is whether it can start sending messages to the
thread, which is already the case even before the thread runs. Just
use the m_running member for this, hence also fixing the fact that this
boolean was written in another thread without a memory barrier.
eThread fixups: Remove "sendcancel" and make sync private

Warn when someone forgot to call kill (which should have been named
join).
Make 'sync' private now that it is unused externally.
Remove the "sendcancel" argument from kill, and move its functionality
into another method called abort_badly().

eHttpStream is the only class to ever call abort_badly, which has been
named "abort_badly" for good reasons (it will leak resources).
picload.cpp: Fix race in thread code

run() returns after hasStarted was called. Move the threadrunning set
to before that call, also to place a memory barrier behind it. This makes it
so that threadrunning is true after run(). Otherwise, there's a tiny chance
that the thread is running but threadrunning is still false.

It would be simpler to just keep that boolean in the main thread.