it's only a provisional solution,
should better be resolved with personalization coming soon
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1411 e54a6e83-5905-42d5-8d5c-058d10e6a962
When adding a new event remove others with the same start time and the
same service id, but possibly different event id.
This reduces the number of duplicates significantly, and is basically
similar to what other projects are doing for this case.
Due to the significant overhead this needs to be explicitly enabled by
exporting the TEST_ADDEVENT environment variable before starting
neutrino for now. Please test and report your findings to the mailing
list.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1410 e54a6e83-5905-42d5-8d5c-058d10e6a962
This allows to play with the ioctls of the frontpanel driver
and the IR driver on the command line.
Can be extended for more drivers in the future.
Expert tool, use at your own risk :-)
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1404 e54a6e83-5905-42d5-8d5c-058d10e6a962
Move the cache lock up to the allocator of the cache pages. There is
a possible race between tuxtxt_allocate_page and tuxtxt_clear_pages.
One customer reported repeated crashes while zapping. Debugging the core dump
lead me to believe there is a race going on as the variables appeared to have been
erased while it was allocating a page, and in the end crashing on an unallocated
page.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1396 e54a6e83-5905-42d5-8d5c-058d10e6a962
of the 'state'.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1394 e54a6e83-5905-42d5-8d5c-058d10e6a962
Just take the write lock right away, to make sure nothing changes the
event lists behind our backs and possibly corrupts the iterator.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1392 e54a6e83-5905-42d5-8d5c-058d10e6a962
The crashes probably were caused by the iterator being invalid
due to concurrent insertion and deletion of events.
An obvious fix is to collect the list of events to delete while
holding the read lock, and later deleting them all in an extra loop.
Turned out to be less complicated than I originally expected ;)
TODO: audit the sectionsd code for similar stuff in other places.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1391 e54a6e83-5905-42d5-8d5c-058d10e6a962
removeDupEvents has some yet to be discovered design problem which
leads to crashes after some time, which smell like stack corruption
or locking issues wrt. the event lists
Obviously it needs some more thought, so disable it for now.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1386 e54a6e83-5905-42d5-8d5c-058d10e6a962
Use the set of events which is sorted by start time and
service id intead of the one sorted by end time to iterate
through the list of events. Fixes a mysterious crash on ppc.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1385 e54a6e83-5905-42d5-8d5c-058d10e6a962
Sometimes the playout centers seem to "renumber" the events, leading
to duplicates.
This "removeDupEvents()" checks for events from the same service, with
identical start time and duration. If it finds such events, it keeps
the one with the lower (== more recent) table_id.
This check is run from the hosekeeping thread.
It could be extended to also remove overlapping events, but this is
potentially more dangerous and can be implemented later still.
As this code is experimental, it is pretty noisy for now. The debugging
output should be toned down later.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1384 e54a6e83-5905-42d5-8d5c-058d10e6a962
the current code has differences in hasFollowScreenings() and
FollowScreenings() leading to different results. hasFollow() returns
true but Follow() then notices that there are actually no repeats.
Fix this by making hasFollowScreenings() generate a list "followlist"
containing all repeats and FollowScreenings() use that list.
An added benefit is that the requested feature to add a possibility to
select one of the follow-ups for a record timer will be also able to
use that list ;-)
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1383 e54a6e83-5905-42d5-8d5c-058d10e6a962
If we get a new epg event whose eventID is already existing, still
replace the existing event if the table ID of the new event is lower.
This comes from the observation that the lower table IDs have the
"more current" events:
Table 0x60-0x6f: other TS, scheduled
0x50-0x5f: current TS, scheduled
0x4f: other TS, current/next
0x4e: current TS, current/next
So, at at least in theory, an event from table 0x4e should always be
"better" than one from 0x60.
If you see any regressions, don't hesitate to report them.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1382 e54a6e83-5905-42d5-8d5c-058d10e6a962
record the originating table ID with every event
if not set (e.g. for events read from saved data), it defaults
to 0xff to make sure it is bigger than a real existing table ID
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1381 e54a6e83-5905-42d5-8d5c-058d10e6a962
The SMS stringinput method has a button bar below the input field,
so the rounded corners are on the button bar instead of the input
field.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1377 e54a6e83-5905-42d5-8d5c-058d10e6a962
