Forums

The calcedSections + seenSections for Freesat is ~12000 (number of sections I saw) x 4 (__u32 set member) x 2 (seen and calced) bytes = 96K. Is 96K a lot? You have more experience of the platform.

not as such, but compared to all other memory users, it is a lot.
If every little feature would consume 96K, we'd be lost

But the biggest user is obviously the epgcache itself, so if we want to save anything, there's the obvious place. Not necessarily the section maps.

I did a little investigation work. I don't think the the subtable version number is consistent across TS's. This makes sense WRT the ETSI EN 300 468 standard. The EIT is probably multiplexed onto the stream by a separate box for each TS after all.

The current EPGCache code doesn't look at the version numbers for a single stream, it just discards all its history at the end of a run. I can change that (and have actually) but it won't work across different TS's (when you change channel everything is lost).

Here's a new version of the patch which never stops looking at the EIT on schedule other TIDs but respects the sub-table version numbering. This should do a better job of staying up to date with the freesat EPG.

so you reckon we don't need a timeout of, say, 60minutes?
(well, not if you really keep the readers running all the time, to find new sections as they are added)

BTW, something else I noticed, haven't yet investigated, the autotimer plugin doesn't seem to find anything which is in the freesat epg.
Can't imagine it does it's own charset decoding, and/or uses the eit directly, I would expect it wouldn't notice how the eit is stored.

By the way, I've stored freesat.c as freesat.cpp, so we don't need eCDebug. Makes the patch a little bit cleaner

BTW, something else I noticed, haven't yet investigated, the autotimer plugin doesn't seem to find anything which is in the freesat epg.

Well there I KNOW that I can't duplicate that since Merlin recorded fine (from Autotimer)! /images/smiley/smile.gif

BTW, something else I noticed, haven't yet investigated, the autotimer plugin doesn't seem to find anything which is in the freesat epg.

Well there I KNOW that I can't duplicate that since Merlin recorded fine (from Autotimer)! /images/smiley/smile.gif

OK, so it must have been something else then.
Weird, the autotimer hasn't let me down recently. (except when they suddenly decided to go case sensitive, and I had to create duplicates of all entries, with all possible case combinations...)

Further cleanup. I took your hint and rewrote the decoder as a C++ class. Also fixed a memory leak that I had introduced. I think this is now well and truely beaten to death!

I'm rather interested by another patch that has shown up on the VDR site. They are reading the TVA CRIDs from the descriptors and using them to "associate" series. This would be better than the auto timer.

EDIT: Removed more cruft from the patch.

Interesting. Any idea for which providers that would work?

I'm not using autotimer exclusively for series, I have several 'record everything with xyz in it' entries. But it would be a nice feature, probably would solve the problem of getting numerous old episodes / repeated episodes, while all you want is the episodes of the new series?

Interesting. Any idea for which providers that would work?

I'm not using autotimer exclusively for series, I have several 'record everything with xyz in it' entries. But it would be a nice feature, probably would solve the problem of getting numerous old episodes / repeated episodes, while all you want is the episodes of the new series?

Looks like the BBC is heavily involved. Members list is on their site http://www.tv-anytime.org/

I've done some more work on the Freesat patch. I started seeing the "hourglass cogs" when using v4 and v5. I think this is because there is too much map / set lookup going on. I've made a more efficient data structure that I'm testing out. It could be used for the standard EIT stuff as well actually.

This is the new attempt. It works a lot better.

thx, seems to work fine.
Only one issue I noticed (took me a while to debug...):
you cannot use eDebug in the freesatHuffmanDecoder destructor, because by then the DebugLock could already be destroyed (and it seems it is), so enigma2 fails to exit, and hangs.

You create a global freesatHuffmanDecoder object, so it's destroyed after everything else in e2.
Virtually all other e2 objects are plugged into the e2 eInit mechanism, so they are deleted in the correct order, when shutting down.
Perhaps it would be nice to connect the freesat huffman object via eAutoInit as well, but for now it's enough to remove the eDebug, or turn it into a plain printf.

thx, seems to work fine.

You create a global freesatHuffmanDecoder object, so it's destroyed after everything else in e2.
Virtually all other e2 objects are plugged into the e2 eInit mechanism, so they are deleted in the correct order, when shutting down.
Perhaps it would be nice to connect the freesat huffman object via eAutoInit as well, but for now it's enough to remove the eDebug, or turn it into a plain printf.

Yes. I wasn't very satisfied with the global object approach. I will take a look at plugging it into the eAutoInit infrastructure.

Yes. I wasn't very satisfied with the global object approach. I will take a look at plugging it into the eAutoInit infrastructure.

Actually if you have any pointers on the scheme used to hook into the shutdown process I'd appreciate it. I did a quick grep on eAutoInit and it wasn't that obvious so far.

One of the simplest examples is perhaps lib/network/http.cpp.
The single line
eAutoInitP0<eHTTPServer> init_eHTTPServer(eAutoInitNumbers::network, "main http server");
takes care of constructing and deleting the object at the right time.

And it's pretty common within enigma(/2) to use something like
static eHTTPServer *getInstance() { return m_instance; }
to use the object.

The remaining challenge is to find the best 'runlevel' for it.

BTW, something else I noticed, haven't yet investigated, the autotimer plugin doesn't seem to find anything which is in the freesat epg.

Well there I KNOW that I can't duplicate that since Merlin recorded fine (from Autotimer)! /images/smiley/smile.gif

weird, it is not supposed to work at the moment, because the epgsearch uses a plain stringcompare on the raw descriptor data.
You probably had a match on a plain now/next descriptor.

I'll try to convert the epgsearch routine to use convertDVBUTF8, hope performance doesn't suffer to much (till now performance is really good, because we can do a title length compare, and only do a stringcompare when the length matches. That will no longer work of course)

for now this seems to do as a workaround

Patch with proper init behavior. Thanks for the tips.

I'll try to convert the epgsearch routine to use convertDVBUTF8, hope performance doesn't suffer to much (till now performance is really good, because we can do a title length compare, and only do a stringcompare when the length matches. That will no longer work of course)

I understand the problem now. I could convert the descriptors when they are stored in the eventData constructor however that would slow down EPG update. Not sure which is better.

I'll try to convert the epgsearch routine to use convertDVBUTF8, hope performance doesn't suffer to much (till now performance is really good, because we can do a title length compare, and only do a stringcompare when the length matches. That will no longer work of course)

I understand the problem now. I could convert the descriptors when they are stored in the eventData constructor however that would slow down EPG update. Not sure which is better.

For freesat that wouldn't matter much, because the epg arrives at a very slow rate.
In general, I'm thinking about moving away from raw eit in the epgstore, so eventually all epg sources will have to convert their received data to utf-8 strings directly.