303 replies to this topic

[awx]

@awx:

Search: adding equal events for TV from Radio too.

Yes, as I am just calling the search function in epgcache and this returns all string matches

[awx]

There is a change to the current GraphMultiEpg that only reads the font name and not the size as it uses the font from the config screen.
I believe this is bad, because now you have mixed places for skinning. Font is set on that screen and also in the skin for ServiceFont.
Either ServiceFont needs an entry in the config screen or the EventFont needs to be moved to the skin.

[mirakels]

There is a change to the current GraphMultiEpg that only reads the font name and not the size as it uses the font from the config screen.
I believe this is bad, because now you have mixed places for skinning. Font is set on that screen and also in the skin for ServiceFont.
Either ServiceFont needs an entry in the config screen or the EventFont needs to be moved to the skin.

Yes, be4ause it is now possible to define the font in the skin, the event fontsize has become a bit of a hack.
The size of the event font has always been settable trough the config screen to adjust it to be suitable for your actual screen. Larger screens can do with smaller fontsize so you can see more of the event title in the event box. Smaller screens may need bigger fonts to make it readable (while the title may be truncated).

I really like to keep the option to change the fontsize in the config screen so you do not need to edit the skin for your local screensize...
Maybe use the fontsize in the skin as a base and let the config screen be a relative adjustment to it...

[mirakels]

Did you notice I added an option to keep passed events info in the cache for up to 2 hours? This helps to still see event info from passed events in GraphMutiEPG. Therefore there is less need to cache the event info in GraphMultiEPG itself and you don't need to get the long eventdescriptions from the cache (saving memory) and let the renderer code do its work in the skin, thats what the rederers are for.

[littlesat]

Just a suggestion. Isn't it possible to make this cache backwards 2 hours default and not configurable? As this is again an extra setting... Or to the max what you can "trace" back"....

[awx]

There is a change to the current GraphMultiEpg that only reads the font name and not the size as it uses the font from the config screen.
I believe this is bad, because now you have mixed places for skinning. Font is set on that screen and also in the skin for ServiceFont.
Either ServiceFont needs an entry in the config screen or the EventFont needs to be moved to the skin.

Yes, be4ause it is now possible to define the font in the skin, the event fontsize has become a bit of a hack.
The size of the event font has always been settable trough the config screen to adjust it to be suitable for your actual screen. Larger screens can do with smaller fontsize so you can see more of the event title in the event box. Smaller screens may need bigger fonts to make it readable (while the title may be truncated).

I really like to keep the option to change the fontsize in the config screen so you do not need to edit the skin for your local screensize...
Maybe use the fontsize in the skin as a base and let the config screen be a relative adjustment to it...

I am not arguing to do away with the option, I just like consistency, if I change the option the rest of the fonts on the screen all stay the same size, and to me that seems like bad behaviour to not be able to either tie them together or have control of all of them.
I like the idea of relative font sizes, that might be a nice solution

[daddelfalk]

Hi,

in order to preserve the old behavior i guess it's disabled by default.

[awx]

Did you notice I added an option to keep passed events info in the cache for up to 2 hours? This helps to still see event info from passed events in GraphMutiEPG. Therefore there is less need to cache the event info in GraphMultiEPG itself and you don't need to get the long eventdescriptions from the cache (saving memory) and let the renderer code do its work in the skin, thats what the rederers are for.

The caching fixes the issue you describe but it also fixes making a request down to the native layer each time you change a selected event.
The size of the data you cache may be large, but GraphMultiEPG anyways neeeds to have a change so that it only requests data for the currently visible service and time window. When that change is in place, the data impact is minimal, performance is increased for all service list sizes and you dont have a penalty just to highlight over a different event.

Maybe my thinking on this is incorrect, but I dont like to have to make multiple calls into the epgcache, especially for single events, but this may be a performance vs memory trade off, which I hope to minimize at some point.

[awx]

Did you notice I added an option to keep passed events info in the cache for up to 2 hours? This helps to still see event info from passed events in GraphMutiEPG. Therefore there is less need to cache the event info in GraphMultiEPG itself and you don't need to get the long eventdescriptions from the cache (saving memory) and let the renderer code do its work in the skin, thats what the rederers are for.

The caching fixes the issue you describe but it also fixes making a request down to the native layer each time you change a selected event.
The size of the data you cache may be large, but GraphMultiEPG anyways neeeds to have a change so that it only requests data for the currently visible service and time window. When that change is in place, the data impact is minimal, performance is increased for all service list sizes and you dont have a penalty just to highlight over a different event.

Maybe my thinking on this is incorrect, but I dont like to have to make multiple calls into the epgcache, especially for single events, but this may be a performance vs memory trade off, which I hope to minimize at some point.

Also keeping a cache of data in epgcache also wastes unneeded data, and depending on how much you have this could be large. That being said I still like the change, because I would most likely keep the data at least 15 minutes longer.

[awx]

Did you notice I added an option to keep passed events info in the cache for up to 2 hours? This helps to still see event info from passed events in GraphMutiEPG. Therefore there is less need to cache the event info in GraphMultiEPG itself and you don't need to get the long eventdescriptions from the cache (saving memory) and let the renderer code do its work in the skin, thats what the rederers are for.

The caching fixes the issue you describe but it also fixes making a request down to the native layer each time you change a selected event.
The size of the data you cache may be large, but GraphMultiEPG anyways neeeds to have a change so that it only requests data for the currently visible service and time window. When that change is in place, the data impact is minimal, performance is increased for all service list sizes and you dont have a penalty just to highlight over a different event.

Maybe my thinking on this is incorrect, but I dont like to have to make multiple calls into the epgcache, especially for single events, but this may be a performance vs memory trade off, which I hope to minimize at some point.

Also keeping a cache of data in epgcache also wastes unneeded data, and depending on how much you have this could be large. That being said I still like the change, because I would most likely keep the data at least 15 minutes longer.

Just a suggestion. Isn't it possible to make this cache backwards 2 hours default and not configurable? As this is again an extra setting... Or to the max what you can "trace" back"....

Maybe a compromise, make this setting triggered by GraphMultiEpg and the round to time interval value. Then guide programs can set it to what they need.
The data you need to keep is mostly related to that value.

onCreate in GraphMultiEPG sets the value for this and when you exit the setup screen of graphmultiepg.

Edited by awx, 30 January 2012 - 12:07.

[mirakels]

Just a suggestion. Isn't it possible to make this cache backwards 2 hours default and not configurable? As this is again an extra setting... Or to the max what you can "trace" back"....

I think this new setting has much more potential that all the settings for th different epg types (e.g freest, mhepg etc)
I think this is quite a usefull setting. In the past I often wanted to see the details of the just finished programs but till now could not do that.
The tradeoff for the extra memory is acceptable considering we all want to have more than 7 days EPG look ahead!

[mirakels]

I really like to keep the option to change the fontsize in the config screen so you do not need to edit the skin for your local screensize... Maybe use the fontsize in the skin as a base and let the config screen be a relative adjustment to it...

I am not arguing to do away with the option, I just like consistency, if I change the option the rest of the fonts on the screen all stay the same size, and to me that seems like bad behaviour to not be able to either tie them together or have control of all of them. I like the idea of relative font sizes, that might be a nice solution

I do agree, but In this case I think it is acceptable as we often have little space to put the event info in. The areas for service names and the long event description are big enough (most of the time...). To allow resizing those fonts to might make it overly complex for most users while only allowing it for eventfont size is stil grapspabel for most users

[mirakels]

Hi, in order to preserve the old behavior i guess it's disabled by default.

in case you mean the epg history, yes its off by default (e.g. 0 hours of history).

in case of the font size, sorry but that is an 'incompatible' change. The first time you open up the epg it will problaby use a huge fontsize as the config reader of enigma2 just takes the values from the config file without checking the bounds of the config setting (that is only done when changing it in a config screen).

[mirakels]

The caching fixes the issue you describe but it also fixes making a request down to the native layer each time you change a selected event. The size of the data you cache may be large, but GraphMultiEPG anyways neeeds to have a change so that it only requests data for the currently visible service and time window. When that change is in place, the data impact is minimal, performance is increased for all service list sizes and you dont have a penalty just to highlight over a different event. Maybe my thinking on this is incorrect, but I dont like to have to make multiple calls into the epgcache, especially for single events, but this may be a performance vs memory trade off, which I hope to minimize at some point.

GraphMultiEPG does only request epg data within the current visible timeframe. So that part seems fine.

I was thinking about only requesting epgdata for the (maxitems) visible services but that looks quite difficult.
The cursor movement code does not have a callback to do some laze data retrieval.
I think the only way to do that is to always have the 'isSelectable()' function active and let that function do epgcache retrieval in some cleaver way.
(e.g. start of with a service list containing None values as the eventslist and when isSelectable() finds a None value it calls fillMultiepg(). fillMultiEPG needs to be updated to only retrieve the epgdata for a limited number of services.
Hm, maybe it can be done...

[mirakels]

] Maybe a compromise, make this setting triggered by GraphMultiEpg and the round to time interval value. Then guide programs can set it to what they need. The data you need to keep is mostly related to that value. onCreate in GraphMultiEPG sets the value for this and when you exit the setup screen of graphmultiepg.

Hm then you still loose data for when you want to check the info of the just ended program.
Maybe better to let graphMultiEPG take this history time into account and take that as a starting time to show the eventinfo.
....
Just tested this and it looks fine! Will push this later on

[awx]

I really like to keep the option to change the fontsize in the config screen so you do not need to edit the skin for your local screensize... Maybe use the fontsize in the skin as a base and let the config screen be a relative adjustment to it...

I am not arguing to do away with the option, I just like consistency, if I change the option the rest of the fonts on the screen all stay the same size, and to me that seems like bad behaviour to not be able to either tie them together or have control of all of them. I like the idea of relative font sizes, that might be a nice solution

I do agree, but In this case I think it is acceptable as we often have little space to put the event info in. The areas for service names and the long event description are big enough (most of the time...). To allow resizing those fonts to might make it overly complex for most users while only allowing it for eventfont size is stil grapspabel for most users

Sounds reasonable to me, no more comments on this from me

[awx]

The caching fixes the issue you describe but it also fixes making a request down to the native layer each time you change a selected event. The size of the data you cache may be large, but GraphMultiEPG anyways neeeds to have a change so that it only requests data for the currently visible service and time window. When that change is in place, the data impact is minimal, performance is increased for all service list sizes and you dont have a penalty just to highlight over a different event. Maybe my thinking on this is incorrect, but I dont like to have to make multiple calls into the epgcache, especially for single events, but this may be a performance vs memory trade off, which I hope to minimize at some point.

GraphMultiEPG does only request epg data within the current visible timeframe. So that part seems fine.

I was thinking about only requesting epgdata for the (maxitems) visible services but that looks quite difficult.
The cursor movement code does not have a callback to do some laze data retrieval.
I think the only way to do that is to always have the 'isSelectable()' function active and let that function do epgcache retrieval in some cleaver way.
(e.g. start of with a service list containing None values as the eventslist and when isSelectable() finds a None value it calls fillMultiepg(). fillMultiEPG needs to be updated to only retrieve the epgdata for a limited number of services.
Hm, maybe it can be done...

So the main problem I have with coming up with a nice solution for this is to properly detect when we have actually rotate our selection from top to bottom, ie. pressing up and looping the list or down. The rest can be done, its just a little painful to get it all working properly. I will make another attempt at fixing this, as I have tried some solutions for this with varying success.

[awx]

] Maybe a compromise, make this setting triggered by GraphMultiEpg and the round to time interval value. Then guide programs can set it to what they need. The data you need to keep is mostly related to that value. onCreate in GraphMultiEPG sets the value for this and when you exit the setup screen of graphmultiepg.

Hm then you still loose data for when you want to check the info of the just ended program.
Maybe better to let graphMultiEPG take this history time into account and take that as a starting time to show the eventinfo.
....
Just tested this and it looks fine! Will push this later on

What I meant was you use the round time to set to how long to keep records. So if we are rounding to 30 minute intervals you keep 30 minutes of data, this allows displaying items to still be kept and guide plugins to show all the data they need, but it was just a suggestion in case adding another config was not an option.

[theparasol]

@Mirakels: Pli integrated graphmultiEPG crashes since openpli 31-1-2012 or 30-1-2012 (not sure)

Crashlog attached, hope you can fix it!

 enigma2_crash_1328032353.zip   3.75KB   5 downloads

[mirakels]

yes, just comitted a fix