awx

I might not be reading it right but this looks like the bit that does the renumbering (lines: 226-228 of the patch)

+   eDebug("Current number '%d' renumbering to '%d' channel '%s'", tmp.channel_num, startChannelNum, tmp.getName().c_str());
+   tmp.channel_num = startChannelNum++;
+   eDebug("Updated number to '%d' channel '%s'", tmp.channel_num, tmp.getName().c_str());

Would this sort of thing work?

if( startChannelNum > tmp.channel_num )
{
   eDebug("Current number '%d' renumbering to '%d' channel '%s'", tmp.channel_num, startChannelNum, tmp.getName().c_str());
   tmp.channel_num = startChannelNum++;
   eDebug("Updated number to '%d' channel '%s'", tmp.channel_num, tmp.getName().c_str());
}
else
{
   eDebug("Current number '%d' not renumbered to '%d' channel '%s'. Number out of sequence.", tmp.channel_num, startChannelNum, tmp.getName().c_str());
   startChannelNum = tmp.channel_num;
}

There are two places something like that would be needed, the loading of the service list and that portiion which is used for updating when a channel is added/moved/deleted.
However there is a problem to doing a check like that, if you want to start the next bouquet at say 1, then it wont be possible anymore and the check would than need to be more complex, obviously not impossible to do but as I havent look at that in sometime I wouldnt be able to say how complex a task it would be.

Yes... but you cannot guarantee that numbers are unique, so e.g. numbers are used twice. So therefore it is not done... I think these numbers should be uniq... By "countring" this the services in the userbouquets this is guaranteed. And with the empty markers we can obtain that the numbers are going through.

And also a big risk as far I can see that settingseditors do not work (they are not aware of any numbering field) and plugins could do not understand something...

I agree with all of that.
Although, I do think that the internal counting mechanism (that is if it hasn't changed) itself should be updated and only done once and not on every input and then updated on an as needed basis, but that not really a big deal as it work as is.

Only I would add that the patch doesn't really allow the normal end user to change this it is more of an advanced feature because you have to hand edit, but that being said introducing it without changing other tools will undoubtedly cause pain as errors are reported on tools that do not correctly ignore the add channel number description.

But with this patch in theory I could put #CHANNEL before every entry so I could have channel 1, then 9 then 47, then 99 if I wanted, or have I understood this incorrectly?

Yes, that is the way that patch was meant to work. It still counts sequentially but you choose to interrupt the counting sequence and have it start at the number you like.
It allows you to number channels as mentioned and if you have channels say 47 through 99, you only need to number 47 and the rest are numbered to 99.
However as I havent looked that the source recently and littlesat has mentioned there was a change, I am not sure how this will fit.

Also caching of event data also prevents if your data in the future has changed then you would have strange behaviour, the event in the list would show one thing while the selected data would show another. Granted that is not something that may happen very often and less often for the user to notice it, but it is something that should be taken into account.

I for one would like to know when event data changes. But I do not know how this change will be visible on screen. I guess the eventid will change so I would expect that the event description 'suddenly' dissappers'. If eventid's are reused the you may see a strange description in relation to the event title (assuming a diffferent program starts).
(if you do a page left and page right all should be fine again though

About the caching in general. I still don't like to do that in GraphMultiEPG. The epgcache already is there to cache. So introducing a second cache seems pointless. Saving the long event descriptions for long service list can take quite some memory. And AFAIK the performance is quit good as it is now. I cannot see any delay between pressing a cursor key and the update of the event description.

epgcache is not really a cache but more of a database then anything else (from the looks of it).

Its up to you if you want to cache the data or not, I run my own version so I am not really affect by this decision. There is minimal memory usage for caching the current page of data. I dont like to display things incorrectly so my vote is for caching instead of presenting the user with incorrect results from time to time. This may be especially confusing for users who do not have underlying knowledge of the situation and will just think there is a bug in the software.

Yes, paging fixes the issue but thats a hack solution to work around an actual problem.
The real solution would have to have some sort of async notification that underlying data has changed, but that is not a trivial task.

I haven't tried the latest PLi GraphMultiEpg how is the text alignment in the list? Does the text still go from edge to edge? The changes I had for this don't seem to be in and I am not sure maybe you fixed this another way.

text alignment is in now. but not the code that goes around the fontheigts. You seem to want to control exact placement of the text bypassing the font renderer.... Vertical aligment on the entry box should be sufficient.
That more or less leaves
- the 'dedicated' keymap files. Why did you want that?
- the TBD stuff. What is the rationale behind that?
- the toggletimer code. Have to look at that...
- caching of the event data. I think that is not really needed.

Also caching of event data also prevents if your data in the future has changed then you would have strange behaviour, the event in the list would show one thing while the selected data would show another. Granted that is not something that may happen very often and less often for the user to notice it, but it is something that should be taken into account.