The idea is that this will become a common API framework for both HTTP
and HTSP. And anything else we might think off.
The only real constraint at the moment is both assume a JSON like input
format (for simplicity) since they currently have that in common.
I actually had all the existing LNBs done but lost the file, doh!
Clearly the current use of the diseqc_setup() function will not work, I
need to read the diseqc spec and decide whether I need to slightly alter
my API setup.
I've added missing config (delsys) to muxes and I've got satconf working
as a full proxy of frontend (may still be a few small issues). Satconf
is not yet doing anything useful, its hardcoded to a universal LNB and
no switch/rotor support.
I have realised that for iptv style setups the current arrangement
will be problematic. The main issue is having the table filter
and top level processing based on the mpegts_input. Since for IPTV
its most likely that we'll only have one mpegts_input with a bunch
of different muxes currently active.
Heading towards the start of a tsfile based system that will be
both a useful debugging tool and also a useful starting point for
the generic mpegts framework
Initial scan now works again
We have a new idnode system that can give an entity a UUID which then can
be looked up externally (webui, etc). Good when browsing stuff
The UUID is supposed to be persisted on on disk when saving enteties
mainly this is just cleaning up the output from the build commands
but also added debian/changelog to ignore file to stop it being
accidentally committed back.
Should a recording be moved (within same dir) the DVR DB will be
updated.
Should it be moved (out of directory) or deleted entirely, it will
simply be marked as missing.
The parent directories are also monitored should they be moved
or deleted.
Currently this supports pause/resume, and speed control. FF up to 4x uses
full frame output, faster than that or reverse uses i-frame only output.
This causes problems with some players and needs work.
Also buffers are done at the subscription level which means the disk space
is not shared even if it holds the same content. And more importantly
this means you cannot yet record the timeshift buffer like on a standard
PVR.
This allows file:// paths to be specified for channel icons even if image
cache support is disabled.
The image cache functionality is compile time optional (for those without
curl support) and also run-time configurable for those that don't want it.
All images, including EPG ones should be cached.
I have decided to include this as there is some suggestion the performance
will be better on ARM (non-x86) processors where we currently have no
optimised code.