Some ideas to improve the Graphical EPG screen

[Huevos]

The other problem is it needs a restart every time you change bouquets otherwise the menu no longer corresponds with the bouquets loaded.

 

[darkdreamingdan]

Tried that, yes corrected my issue and tested more. I'll be honest, don't think we'd consider adding that part.

Can you please post links to the code required for Channel numbers only in bouquets only and we'll take a look. Thanks.

Before I spend any time removing what I deem to be a useful feature, I implore you to see the value in this functionality. I get that it's very 28.2-centric but it effectively let's you break free of the constraints of the E2 numbering system when used correctly. Simply have an initial bouquet with any channel numbers you want - then all other bouquets' channel numbers are abstracted away. Of course there are drawbacks, and it's mainly useful to users only using one provider at a time, but I believe most of them can be resolved - and ultimately it should be up to users to decide.

I would rather spend my time trying to find a way where this functionality can remain in Vix in some form. I'm open to trying to find a way to make this tie in better with E2 if that's what you want - but in my opinion the entire Bouquets system is severely limited already and this was the easiest solution I could come up with.

 

[ketmp]

I would like say that whilst I understand that Vix is not just for 28.2, I'm sure that majority (if not at least a fair few) of Vix users do use it for 28.2, albeit not all maybe on it's own.

I think @Killercow's coding improvements (based on Matt007's and others ideas) is a great opportunity for Vix to stand out even more than other images than it does now. I'm not aware of other images that have all these proposed features in their Graphical EPG images as standard. Vix could be the first and improve on an already great EPG system (when compared to some images).

Yes, some of the proposed features may not suit everyone but that's why they can effectively be turned on/off. Those that don't wish to use it don't have to. Isn't this the way most other features work in Vix as not everyone has need for all the features Vix offers. It's effectively about giving us Vix users even more choice.

For example, the customisable coloured button options I've not noticed such feature in any of the main images built-in EPG system.

 

[Rob van der Does]

Point is: the proposed change was about two things. That's not good. Every amended/bew functionality should be in it's own commit. That's the only way things can be changed/tested/committed, and the only way GIT-history is useful.
And I can't see us accepting anything that can't be used universally, anything that's only useful for a specific setup. Even when it can be turned On/Off.

 

[Huevos]

Adding features is a balance. When coding in the future one has to be careful not to break that feature. The more features added the harder that becomes. And when feature the needs to be disabled just to run a basic setup like Scillian's it doesn't make sense adding it.

 

[ketmp]

...And I can't see us accepting anything that can't be used universally, anything that's only useful for a specific setup. Even when it can be turned On/Off.

It's not just 28.2 (although obviously majority of Vix users would use it for 28.2), to the best of my knowledge it can be used by Virgin customers as well and probably other single ABM providers (although I can't actually test this).

Sometimes features are included for a specific setup/group because it's not always possible (for various reasons) to have it available to all users (although this would be nice). One such thing is XBMC is only available to specific setup/group of users and not all users.

The customisable coloured button (when coded) would be available to all users as that isn't based upon a specific group of users.

What features do you think could possibly be included (once tested, etc)?

Thanks for your time and explanations.

 

[Rob van der Does]

Sometimes features are included for a specific setup/group because it's not always possible (for various reasons) to have it available to all users (although this would be nice). One such thing is XBMC is only available to specific setup/group of users and not all users.

I don't think ViX has any option/setting for any specific group/user/setup.
Certainly not XBMC: it's available for everybody who has a box that supports this.

 

[darkdreamingdan]

Point is: the proposed change was about two things. That's not good. Every amended/bew functionality should be in it's own commit. That's the only way things can be changed/tested/committed, and the only way GIT-history is useful.

So what you're saying is, for two closely related features (which have already been tested by multiple users) to be merged into a testing branch (Dev), it needs to be split into several commits (which it is within my own fork) so that they can be tested(???). This is pretty outlandish, and is trying to argue against a feature in a way that's completely unrelated to the merits and totally related to bureaucracy - despite us asking multiple times how to present source code to Vix with no guidance.

And I can't see us accepting anything that can't be used universally, anything that's only useful for a specific setup. Even when it can be turned On/Off.

I can't say this any better than ketmp, but the point is: it can be used universally. This feature applies to anyone who wants to use whatever channel numbers they want without duplicates - they just have to setup a bouquet with the correct channel numbers. For many users, ABM does this for them already. Here are some examples of current settings where similar logic could be applied:
Alternative numbering mode
Enable multiple bouquets
Enable unlinked bouquets

Adding features is a balance. When coding in the future one has to be careful not to break that feature. The more features added the harder that becomes.

Yes, this true. However, based upon the code submitted, can you suggest any plausible scenario where this is possible? It's just speculation unless you can quantify any measure of risk.

And when feature the needs to be disabled just to run a basic setup like Scillian's it doesn't make sense adding it.

No, you're wrong. It just doesn't need to be enabled. The difference here is staggering.

I've still heard absolutely no suggestions about how this same functionality can be achieved while being more 'universal'. Seriously, if you're not happy with it, let's suggest a way to move forward.

 

[ketmp]

I don't think ViX has any option/setting for any specific group/user/setup.
Certainly not XBMC: it's available for everybody who has a box that supports this.

Sorry I wasn't clear in my post

XBMC is only available to those that have a box that supports it (as you said) which isn't that many as far as i'm aware when compared to how many boxes you support and in similar circumstances these proposed features are also available to those that can make use of it (which is probably more of Vix customer base than boxes that support XBMC).

I was just trying to say that not all features Vix has can be used by ALL users (for various reasons including individual setups, boxes, etc).

 

[Rob van der Does]

So what you're saying is, for two closely related features (which have already been tested by multiple users) to be merged into a testing branch (Dev), it needs to be split into several commits (which it is within my own fork) so that they can be tested(???). This is pretty outlandish, and is trying to argue against a feature in a way that's completely unrelated to the merits and totally related to bureaucracy - despite us asking multiple times how to present source code to Vix with no guidance.

It's not only about testing, but also about history as I tried to explain before.
GiT history is very important for maintaining of the software and for debugging. That simply requires that a commit is as small as possible, and certainly only related to one issue.

No, you're wrong. It just doesn't need to be enabled. The difference here is staggering.

But enabling it shouldn't give issues, for nobody and for no setup. That's one of the requirements we have and the thing we test as good as possible every time we add or amend functionality.

Seriously, if you're not happy with it, let's suggest a way to move forward.

That has been suggested/asked already: supply a patch/pullrequest holding only the service numbering in EPG. That will probably be accepted.

Sorry I wasn't clear in my post

XBMC is only available to those that have a box that supports it (as you said) which isn't that many as far as i'm aware when compared to how many boxes you support and in similar circumstances these proposed features are also available to those that can make use of it (which is probably more of Vix customer base than boxes that support XBMC).

I was just trying to say that not all features Vix has can be used by ALL users (for various reasons including individual setups, boxes, etc).

Of course different boxes have different options, depending on hardware & drivers: some have HDMI-in, transcoding, multiple tuners, scart, HbbTV, blindscan etc etc and others have not. Of course we (try to) support all options a specific box has.
But I fail to see the relation between this and the subject at hand, which is a general E2-change and is hence applicable to all boxes.

 

[darkdreamingdan]

But enabling it shouldn't give issues, for nobody and for no setup. That's one of the requirements we have and the thing we test as good as possible every time we add or amend functionality.


That has been suggested/asked already: supply a patch/pullrequest holding only the service numbering in EPG. That will probably be accepted.

The history is there as part of the pull request, and the commits are already staggered. I also don't agree that it causes 'issues' for anyone - there's no crashes or errors, it facilitates the desired behavior in all circumstances.

Regardless, I can split it into a separate pull request (that seems to be the issue here, not commits), but what I meant is that no one has suggested how duplicate channel numbering can be elegantly avoided in Vix. Primary Bouquets is the first working solution (afaik) that tackles this problem.

 

[Peterj]

I did some testing with the G-EPG numbers (Had no change color button option, skin issue?).
I created 4 bouquets.
1st: cable all channels
2nd: cable FTA
3th: Freesat all channels
4th: Freesat FTA
Alternative numbering on, no use of primary bouquet.

This displays the numbers in all bouquets the correct way. no issues.
Alternative numbering off:
Channel numbers correct in all bouquets, no issues.

Choose first bouquet as main bouquet:
channel numbers in 1st bouquet ok, in second bouquet it has the numbers of the first bouquet. Also when you are in the 2nd bouquet and choose another channel using the G-EPG, suddenly you are back in the 1st bouquet. That is not wanted behavior.
The 3th and 4th bouquets has there own channel numbers.

It doesn't matter if you have alternative numbering ON or OFF, it's the same behavior.

During testing I had 1 BSOD when I choose G-EPG.

IMO that 'choose primary bouquet for numbers' is complete unnecessary and give you unwanted behavior of channel picking.
Without it, it acts like it should be.

 

[abu baniaz]

The primary bouquet thing is for people who have the large Sky UK bouquet. If you haven't got that, leave the setting as default. It is optional to switch it on.

Just like Virgin EPG is useless to lots of people and at the same time useful to lots of other people. The same applies here.

If you can upload the crashlog, it can be remedied.

 

[Rob van der Does]

The primary bouquet thing is for people who have the large Sky UK bouquet. If you haven't got that, leave the setting as default. It is optional to switch it on.

An option that causes issues for a normal setup will not be taken aboard of ViX.

Just like Virgin EPG is useless to lots of people and at the same time useful to lots of other people. The same applies here.

That's a different story: turning 'Virgin EPG' on doesn't give any issue at all when you don't receive the data.

 

[Peterj]

The primary bouquet thing is for people who have the large Sky UK bouquet. If you haven't got that, leave the setting as default. It is optional to switch it on.

I don't understand what a large bouquet has to do with messing up channels in another bouquet.
A bouquet is an user defined channel list. You put channels in it, in an order you want and (when you know how to do it) you give it channel numbers you want (like ABM is doing it for you).
Why should there be an option to mess up your channel numbers in a bouquet and worse, when you choose another channel using G-EPG you suddenly hop to the "main" bouquet?

 

[Huevos]

no one has suggested how duplicate channel numbering can be elegantly avoided in Vix

Channel numbers do not exist in E2. The numbers shown in the list are just accumulative from the start of the first bouquet but in no file does a numbering system actually exist and correlate to services. If you want channel numbers build an SQL database of channels and have the channel numbers as one of the columns. Lots of work, but the correct way to do it.

 

[abu baniaz]

allowing unlinked bouquets messes up order of bouquets. we have that option in image too.we imported it as default of being enabled. changed it to disabled because we discovered issue with it.

alternate numbering spoils some people's bouquets. perfect for others.

there is no numbering in E2. it is just the order they are loaded.

 

[darkdreamingdan]

Choose first bouquet as main bouquet:
channel numbers in 1st bouquet ok, in second bouquet it has the numbers of the first bouquet. Also when you are in the 2nd bouquet and choose another channel using the G-EPG, suddenly you are back in the 1st bouquet. That is not wanted behavior.
The 3th and 4th bouquets has there own channel numbers.

What do you mean "main bouquet"? I assume you mean Primary Bouquet? If so, this is /exactly/ the way it's meant to work. The Primary Bouquet has precedent over any other Bouquets, and where a service exists in the Primary Bouquet, this one is preferred. The idea is, you can assign channel numbers however you like in your Primary Bouquet, and create any other categories without worrying about cumulative numbers. If a service exists in a Primary Bouquet, it will always override a matching service in other bouquets. If you want to make use of the Primary Bouquet it's simple - just create a Bouquet list with all the channel numbers you want and set this is as the Primary Bouquet.

There is no need for you to use a Primary Bouquet because it seems you don't have a need for this functionality, whereas many others do. Simple.

As for the crash, it seems to be a crash in Enigma2 core and I can't trace it back to any python or EPG related activity. Keep an eye out if more crashes happen.

 

[darkdreamingdan]

Channel numbers do not exist in E2. The numbers shown in the list are just accumulative from the start of the first bouquet but in no file does a numbering system actually exist and correlate to services. If you want channel numbers build an SQL database of channels and have the channel numbers as one of the columns. Lots of work, but the correct way to do it.

Yes, a database of channels makes sense, and I had considered that. Actually, i think XML is more suited to this task as there is not going to be frequent reading/writing, so SQL would be a bit ott. The issue with this approach is that it would require every Bouquets maker (including ABM) to be aligned with this channel creation approach. Not only is this a large task in itself (given how difficult it is to get anyone to implement this relatively harmless change already) but it may not comply with OE-Alliance compatibility.

Let's not get into symantics over Channel Numbers not existing in E2 - i've heard this several times and I'm aware. There are numbers that appear when i select a channel. I'm going to call these Channel Numbers, regardless of where they're inherited from. You can't tell me that the numbers I type to Zap to a channel are somehow irrelevant. So, this is built for the users of today. The users that don't care and don't even know that E2 doesn't have channel numbers. The users that type a number to jump to a channel. The users that have requested more than once for improvements to the system.

 

[abu baniaz]

The only objections have been from people usingvthe primary bouquet feature when they should not have.

Might as well as add numbers only for now. 28.2 users who complain about numbers not tallying can be told to use the main bouquet =HD