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
Origin commit data
------------------
Commit: 3d192a084b
Author: Thilo Graf <dbt@novatux.de>
Date: 2011-04-17 (Sun, 17 Apr 2011)
Origin message was:
------------------
*neutrino service menu: infomenu item removed
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
Origin commit data
------------------
Commit: 4ed9e079ae
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-17 (Sun, 17 Apr 2011)
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1407 e54a6e83-5905-42d5-8d5c-058d10e6a962
Origin commit data
------------------
Commit: 102e156fc3
Author: gixxpunk <thomas.harfmann@gmail.com>
Date: 2011-04-17 (Sun, 17 Apr 2011)
Origin message was:
------------------
- try to fix wrong wakup channel after standby recordings. This is a very hacky, but should work. Please don't hesitate to revert my changes if you have a proper solution for this problem.
git-svn-id: file:///home/bas/coolstream_public_svn/THIRDPARTY/applications/neutrino-experimental@1407 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
Origin commit data
------------------
Commit: 3422f5f719
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-16 (Sat, 16 Apr 2011)
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
Origin commit data
------------------
Commit: d26267a541
Author: nightshad <nightshad@e54a6e83-5905-42d5-8d5c-058d10e6a962>
Date: 2011-04-12 (Tue, 12 Apr 2011)
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
Origin commit data
------------------
Commit: df3d2fbc3b
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-11 (Mon, 11 Apr 2011)
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
Origin commit data
------------------
Commit: c5ae25e66d
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-11 (Mon, 11 Apr 2011)
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
Origin commit data
------------------
Commit: f9250015c7
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-11 (Mon, 11 Apr 2011)
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
Origin commit data
------------------
Commit: 8f704427b8
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-11 (Mon, 11 Apr 2011)
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
Origin commit data
------------------
Commit: 13b67c5da5
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-10 (Sun, 10 Apr 2011)
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
Origin commit data
------------------
Commit: 90164158b3
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-10 (Sun, 10 Apr 2011)
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
Origin commit data
------------------
Commit: 04bd1ce20b
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-09 (Sat, 09 Apr 2011)
Origin message was:
------------------
sectionsd: replace existing events with event from lower table ID
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
Origin commit data
------------------
Commit: 72149b63a4
Author: Stefan Seyfried <seife@tuxbox-git.slipkontur.de>
Date: 2011-04-09 (Sat, 09 Apr 2011)
