Neumo Release 3.4.0.r3855

Status
Not open for further replies.

tani1

Staff member
Super Moderator
Messages
17,767
ReleaseNotes.neumo.3.4.0.r3855
I: improvement
B: bugfix

I: The whole code has been adapted so that it can be compiled
with gcc-4.2.4. Because of the presence of binary kernel modules
it is not possible to compile it with any other compiler.

If you wish to compile yourself, get the required toolchain at
http://neumoteam.org/browser/contri...k400s_gcc4.2.4_linux2.6.9_eglibc2.10.2.tar.gz
untar it and rename the main directory to /usr/local/x-tools

If you wish to rebuild the toolchain, configure it as follows:
-kernel 2.6.9-relook400
-binutils 2.19.1
-gcc 4.2.4 with c++ support
-egclib 2.10
-gmp 4.3.1
-mpfr 2.4.1

I: Some important libraries (like libc) included in the images have also
been updated by copying from the sys-root produced by crosstool-ng.
As a result the code now uses the posix-compatible NPTL as a thread
library instead of the ancient linuxthreads. Threading is now much
more efficient. In top, relook now appears as a single process.

I: Implemented epg store. This epg store is much faster than dbepg.dat
enables relook to store epg records much faster (10-50 times faster).
This means that epg is loaded faster and that it is no longer needed
to buffer epg data in memory before writing it to the epg store (in the
existing code this was needed in order to keep up with the incoming
dvb data stream). As a result, less ram is used. Also it is now possible
to remove the epg writer thread.

The epg store has also been designed to perform a minimal number of
disk accesses. Together with the reduced ram requirements and the fact
that we can remove one thread, the load on relook due to the epg code
is significantly lower, which should reduce pixellation.

The epg database is also a lot more compact and uses less
disk space.

The code has been designed to support a minimal number of operations
(in addition to storing data) efficiently:
-looking up data for one channel
-looking up now-next data for all channels
-looking up data for all channels in a given time range
-deleting old data

Internally the epg store indexed data by sat_id, transponder_id,
service_id and start_time. With the exception of "sat_id" these
values are completely independent of dbepg.dat. This makes it
possible to copy epg store's from one relook to another or even
between other 32bit machines with the same byte order, with the
only restrictions that the machines have to use the same "sat_id"
values. On the other hand the old dbepg.dat was tied closely to
db.dat and could not be exchanged between systems with a different
db.dat. Also, this approach makes the code faster.

The new epg store is based on a modified version of the post++ code
and persistently stores data structures on disk. Due to the use
of transactions it should survive power failures or crashes.
The main data is stored in a file with extension .odb. After
a crash (or when relook is busy) there will also be a .log
file, which contains transactional data which is used to bring
the database in a consistent state.


The data is byte order sensitive and thus cannot be read on other
platforms (e.g. i386 or x86_64) without transforming it first
(to be implemented).

The code allows only one process to use the epg store simultaneously.
Within that process, only one thread can write data.

Internet epg is not yet supported, but will be implemented as follows:
it uses the same code, but will write to a second epg store. Relook
will read epg data from this store in addition to from its own epg store
Since the new code is also much faster for reading data, the user should
not notice a delay.

To avoid crashes when internet epg is updating its epg store, the simplest
solution is that internet epg creates a new store in a temporary file and
then (when done) moves the file into its correct location. Relook will
check if the file has changed and then reopen it.

With minor changes, the epg code could also store all epg data in ram.
This would be useful on systems without a hard disk, or when the user
does not want disk spin ups. The main remaining question is how to
enforce memory limits in a way which is both efficient and useful.

I: Channel list now allows viewing detailed epg info for the program
currently running by pressing info. Channel editing has now been attached
to the blue key.

I: Searching epg records is now very fast.

B: In grid epg, when searching by name, and then browsing the list of searches,
the current cursor position was not always highlighted.

B: Buffer overrun in SI table parser code causing random data corruption.
Probably was the reason for sporadic corruption of dbepg.dat

B: List of symbol rates incomplete in channel search

B: Hang when pressing power off key in channel search, usals,
lnbsetting, diseqc mode

B: Problem in parsing SI tables because data read from closed file descriptor.

B: Incorrect deadline computation in code which waits on lock. A value
of more than 1000 000 000 is illegal in struct timespec. It is unknown
what the effect was in the original code, but with the new compiler
it caused problems.

B: Several tools producing uboot images (mkwelcomeimg, mkubootimage)
malfunctioned when compiled on computers with 64bit architectures.
This has been fixed.

B: Nothing appears on screen when relook asks to erase database or
format hard disk. Welcome image not shown. The bug was due to
incorrect uboot images being created.

B: Newly installed welcome image appears upside down.

Known bugs:
------------
-in epg search: key left/right is supposed to move to the next channel
but doesn't.

-in epg search, when entering virtual keyboard, key left/right does not
work until up/down has been pressed.

-Recording from channel epg (and in other ways) does not always work
Live on one channel. Record other channel using channel epg
=> recording does not start
Pressing record once more in channel epg tunes to bbc1 but a second press does
not stop recording

-now/next does not work in channel epg. Not implemented. It seems that
a variant of the channel list (showing epg information next to each
channel and having perhaps less possible buttons to press) would be
better suited. The problem is that now-next is only useful if data
is sorted by channel and if channels are ordered according to the
user's wishes. If the data is gotten directly from the epg store,
this is not the case and sorting afterwards would be slow and
memory intensive. The channel list has all the functionality already
implemented. The adaptations needed are
-allow more room on screen for epg data
-add a button for switching between now/next/service (service returns
to channel epg). Problem: there is no room for extra buttons, and
the most obvious buttons are already in use

-libchash (google hash) seems to free non-allocated data, without
much practical consequences so far

-half of subtitle remains on screen after commercials start on English
channels (e.g. E4). This might be related to a change in reen aspect
ratio change which often happens at this point.
 
Status
Not open for further replies.
Top