3 replies to this topic

[awx]

Here is a patch for enigma2 to enable caching of the content descriptor and allow the data to be retrieved with lookupEvent and search.

The function declaration in event.h may need to be moved so that we can request the information from the event in python.

Currently this will allow listing event categories such as (Movie/Sport/etc...), to specific highlight when we show the information.

For a future release I will look into adding a search option for the content descriptor, so we can perform searches like, show all movies or show all sporting events.

Content descriptors are typically 2 bytes for the descriptor header, and 2 bytes for the classification. However since the descriptors do allow for multiple classifications you could potentially have 2 bytes descriptor and n*2bytes classifications. This should therefore have a minimal impact on memory usage.

Attached Files

•  patch.tar.gz   1.93KB   13 downloads

[greatred]

This is looking very promising. Bringing "Content Description" will take the EPG functionality to the next level. Cheers awx
Can any o the Devs put a comment on this?

[MiLo]

Storing the genre in an std::list will actually consume at least 2*(sizeof(void*)) + sizeof(int) bytes per entry. It's stored on the heap, so it also needs allocation overhead, so I estimate that storing that data will cost more like 20 bytes per event. That's slightly more than your estimation of 2..4 bytes.

And before committing this, I'd like to see it actually put to use. The epgcache is already the biggest memory hog on the box, if we're gonna make it hog even more, it better be for a good reason. Until proven wrong, I estimate that 95% of the providers don't bother to supply this at all, or supply wrong information. So I'd like to see some "proof" that this is actually useful.

Step 1: Reduce your memory footprint (I can forewarn you that a std::vector consumes about 16 bytes too).
Step 2: Show that it's really useful.

[awx]

Storing the genre in an std::list will actually consume at least 2*(sizeof(void*)) + sizeof(int) bytes per entry. It's stored on the heap, so it also needs allocation overhead, so I estimate that storing that data will cost more like 20 bytes per event. That's slightly more than your estimation of 2..4 bytes.

And before committing this, I'd like to see it actually put to use. The epgcache is already the biggest memory hog on the box, if we're gonna make it hog even more, it better be for a good reason. Until proven wrong, I estimate that 95% of the providers don't bother to supply this at all, or supply wrong information. So I'd like to see some "proof" that this is actually useful.

Step 1: Reduce your memory footprint (I can forewarn you that a std::vector consumes about 16 bytes too).
Step 2: Show that it's really useful.

You are looking at the memory foot print for storing the actual parsed event.
Epgcache does not store the data this way.
The portion you are looking at is when we find an event we are interested in, we parse that event which creates the object in question that has this list. So its not as bad as what you are stating.

Ofcourse the foot print of these objects could be reduced if needed.
If you want to look at the memory usage of this data then we have the following.
For a list of 5 channels displaying 2 hours of data and say you have 5 minutes programs on each of those channels. Then you would have a 120 events * 20 bytes 2400 bytes of data being used for that data display a list like that.

I already have a modified version of GraphMultiEpg to make use of some of this data, but I will make some changes to make more useful use of this data.