Optional search restriction in epgsearch

[prl001]

There have been a number of requests on the Beyonwiz forum to allow epgsearch to restrict its search to the current bouquet, especially for users who normally have "Enable multiple bouquets" disabled.

I intend making the search choices "whole EPG/current bouquet/current channel".

I'm happy to implement this, but I have a question about what the default setting should be. For user convenience, I'd prefer the default to be "current bouquet". Backwards compatibility would argue for "whole EPG".

Does anyone (especially the oe-alliance reviewers) have opinions either way on this? Or even whether it's a good idea at all?

[RobvanderDoes]

1- Where is this search-choice being located (in the GUI I mean)? 2- Please let 'all bouquets' be the default value.

[RobvanderDoes]

And speaking for myself: sometimes I would like to search only in the active service, an other time in the active bouquet and sometimes in all bouquets. So maybe on hitting 'search' the question service/bouquet/all should arise? And then it would be a good idea indeed :+1:

[arn354]

add a epgsearch config option config.plugins.epgsearch.mode (all, current bouquet, current service) use boxbranding to set default config.plugins.epgsearch.mode for beyonwiz to current bouquet (else "all"). The default behaviour should not change in my opinion.

[RobvanderDoes]

Then I would need to enter the setup every single time I want an other search :-1:

As I said: the question where to search on every search would be ideal IMHO.

[prl001]

How about a config.plugins.epgsearch.defaultmode setting instead to set the search mode popup's default? That way you can choose whatever search you want at search time, but have your most common search directly on OK.

I like the idea of using boxbranding to select a different setting default on the Beyonwiz, if I want to change the Beyonwiz default.

[arn354]

How about a config.plugins.epgsearch.defaultmode setting instead to set the search mode popup's default? using boxbranding to select a different setting default on the Beyonwiz

Thats what i meant.

[prl001]

But perhaps better might be: Search scope: All bouquets/Current bouquet/Current service/Ask Default search scope: All bouquets/Current bouquet/Current service

where "Default search scope" is only visible and active when "Search scope" is "Ask", and it preselects which popup item has focus, so that if you have "Ask" set, YELLOW, OK always does your favourite search.

That way, people who want to be able to chose a fixed scope have no popup and people who want a popup can have the popup focus preselect to their usual search.

[arn354]

Good point

[RobvanderDoes]

I was about to suggest that; sounds good to me.

[AbuBaniaz]

A bit unrelated to the topic, but as you are looking at EPG search, I might as well as ask now.

Can you add the orbital position in the result too? This is very handy for users with the multiple tuners. One of our members has the same services on 28.2E, 9E and DVB-T. Having these will make it easy to set a timer on a specific tuner.

On OpenVix we added it to History Zap. https://github.com/OpenViX/enigma2/commit/cc0b141180ae9540350604e5bdfae89019cd3fd5

I attach a picture of how history zap looks like

[RobvanderDoes]

Would be great if orbit pos could be added!

[prl001]

Unfortunately, I have no access to an enigma2-based satellite PVR, so I would have no way to test adding orbital position to the search results. The Beyonwiz PVRs I have access to only have DVB-T tuners, and I have no satellite subscription.

[RobvanderDoes]

Could I be of help? Either by testing or allowing you entry to a box?

[prl001]

Thanks, Rob.

Having a tester might be enough, but I'd need to have a quick look at the code to decide whether I can fake up the orbital position on a DVB-T service for my own testing before giving the code to someone to test live.

That will have to wait til tomorrow. It's bedtime here in Australia :)

[RobvanderDoes]

OK, then being in contact via Skype seems the way to go (robvanderdoes). I'm an early riser in Europe, so we might have some overlapping working time :)

[Huevos]

1, current default is all services, i.e.includes services not in a bouquet. So options would be, all services, services fron all bouquets, services from current bouquet, current service.

2, orbital position can get extracted from service ref. Same for terrestrial and cable.

[prl001]

So options would be, all services, services fron all bouquets, services from current bouquet, current service.

That can be done.

I've had a look at the orbital position code in OpenViX/enigma2, which seems to be pretty much a copy/paste of the code in Components/TimerList.py in the Beyonwiz enigma2. So that should be easy.

Rob, I'll get back to you to arrange a contact time when I have something worth looking at.

[Huevos]

Was not copy and paste code.

[prl001]

OK. "well established code pattern", then :)

[prl001]

EPGSearchSetup writes setting description texts into a Components.Sources.StaticText widget named "status". The convention for the Beyonwiz enigma2 description text widget name is "description". The "status" widget doesn't seem to have any function.

I can make the description work just by adding a Label() widget in self["description"].

Should I get rid of EPGSearchSetup.self["status"] or leave it as it is for backwards compatibility?

[RobvanderDoes]

'Status' has been used for [Recording/Timeshift] modify code to use main setup.xml file. ViX doesn't use this any more (old Recording_timeshift file), but other teams might. See https://github.com/OpenViX/enigma2/commit/3177f5ee1f86166f8b308006ac344d4963b5cdc4#diff-d4e91cd32603b597a4b04dff33cc86a2L146 It seems safe to remove. And if you do that in a separate commit it will be easy to revert when required.

[prl001]

OK, I'll do it that way, then.

[prl001]

OK, if the search scope is "ask user", should it ask only on entry to the EPG Search screen, or on each search, e.g. from YELLOW New Search, or from MENU>Show search history?

I.e. should "ask user" be per session or per query?

I've already got the mechanism in place for remembering the last answer to "ask user", it's needed at times like when the callback from timerAdd() calls refreshlist().

[RobvanderDoes]

For me the setting 'ask user' should be applicable to all possible searches.

[prl001]

Good. That's how it is now :)

[prl001]

I've created a pull request for the changes that add search scope specification (all services/all bouquets/current bouquet/current service/ask user) to EPG Search.

As a bonus, I've thrown in a shortcut to EPG search history on long-YELLOW.

I'll do the request for orbit position display in the search results as a separate pull request, because it's really unrelated to the search scope.

[RobvanderDoes]

Thanks, I'm about to test it. And indeed: orbit-pos should be in a different commit. And what about the 'status' widget?

[prl001]

And what about the 'status' widget?

Taken out in a commit of its own in the search scope pull request.

[prl001]

Rob has merged my pull request to add search scope to EPG Search. Unfortunately, it still has the buggy code in it that causes the crash on exit from EPG Search Setup on (at least) VIX. Please don't use it yet.

[RobvanderDoes]

Well, sorry, there were quite a few recent requests, so I thought all was in already. Anyway: you have the fix ready :)

[prl001]

It's OK. I just wanted to make sure everyone knew that it wasn't quite ready to use.

I'm currently testing my implementation your request to have a "Setup" entry in the "ask user" menu. I've already committed the other fixes to a new branch in my fork.

[prl001]

Does this look like a reasonable layout for the orbital position? Don't worry that the same service names are both DVB-T and at random positions in the sky, it's synthetic data to test the layout.

[RobvanderDoes]

Absolutely!

[Huevos]

That is going to mean half-screens don't have sufficient room. Not sure of the best way to tackle that. I think Abu's idea was to have it at the bottom of the screen, but this layout is more useful, apart from the problem with the half screen skins.

[RobvanderDoes]

@ Huevos: this is the layout of the embedded screen. So if not skinned, this is what will show, and if skinned the skinner is free to make the lay-out as he deems fit. So IMHO this is perfect.

[Huevos]

Also, if you look in the channel list screen, it also contains the transponder data. That means when starting a recording from that screen you know in advance the sub-band, which allows you to get the maximum from the tuners configured.

[Huevos]

Ok Rob, but means it will need looking at in some of our skins.

[RobvanderDoes]

but means it will need looking at in some of our skins.

I'm following this :)

[prl001]

I think Abu's idea was to have it at the bottom of the screen

I don't know what Abu's intended layout is. Abu's screen shot shows the orbital position per list entry, not at the bottom of the screen, but the list entries are multi-line.

[RobvanderDoes]

Please don't worry about the lay-out of the embedded screen's. Anybody can skin them for their own images/purposes. As long as all elements are available.

[prl001]

this is the layout of the embedded screen. So if not skinned, this is what will show, and if skinned the skinner is free to make the lay-out as he deems fit.

No, the layout I posted was from the EPGSelection screen skin in the Beyonwiz easy-skin-aus-hd skin, not an embedded skin (neither the EPGSearch nor the parent Beyonwiz EPGSelection classes have embedded skins), but that only sets the list width. The field widths come from the implementation of Components.EpgList. The list width in the Beyonwiz skin is 1175 px, out of 1280. I've stolen 100 px from the service name/title field, with 80 px for the orbital position (right aligned) and 20 px space to the service name. There's probably a bit of space that can be spared there.

One thing about the Beyonwiz skin is that it leaves far too much space for the short-form date. I'm not sure whether other implementations of Components.EpgList are as wasteful of space in that field as the Beyonwiz skin is.

@Huevos, what's the list width in the half-screen skin you'd want to use?

[prl001]

Please don't worry about the lay-out of the embedded screen's. Anybody can skin them for their own images/purposes.

I'd like not to worry, but the list field widths are set in the code, not in the skins. The skins only set the list width. There are no embedded screen skins to worry about. EPGSearch getls the basic field widths from the field widths in the image's EpgList class.

[Huevos]

Rob can answer on the screen width, but I guess it depends if it is a 720 or 1080 skin.

In "channel list" transponder details show on the bottom line. Details are complete, not just position. This can be helpful when scheduling a recording when it is essential to know the sub band of a concurrent recording, for example with loop-through or FBC tuners. Transponder details are displayed on highlighting the list item.

[RobvanderDoes]

the list field widths are set in the code

Well, that can be a problem than. All fields should be freely skinnable, with elements like fontsize, fonttype & itemheight. And a fixed width can never be good for SD, HD & FHD screens.

[RobvanderDoes]

As an example of how to overcome such things, I show you a snippet of skin code taken from the channelselection of a ViX-HD skin:

        <widget name="list" position="10,82" size="660,565" selectionPixmap="ViX-Common/buttons/FocusBar_H36x660.png" backgroundColor="black"
                        foregroundColorEvent="event-frgrnd" foregroundColorEventSelected="#00202020" foregroundColorServiceNotAvail="verydarkgrey" serviceItemHeight="36"
                        serviceNumberFont="Regular;25" serviceNameFont="Regular;25" serviceInfoFont="Bold;22" transparent="1" zPosition="3" scrollbarMode="showOnDemand"
                        backgroundColorMarkedSelected="red"/>

But unfortunately I can't help you with the underlying python-code. There are more examples like this e.g. in Timer-entry and Autotimer-entry.

[prl001]

It's clear from the channelselection skin snippet that the field widths in that list are set in the code. Otherwise it'd use a TemplatedMultiContent converter.

But I can try doing an EPGSearch layout that will still work with a list width of 660 px.

[prl001]

Also, if you look in the channel list screen, it also contains the transponder data. ...

Did I just see some goalposts go whizzing past? ;)

[AbuBaniaz]

If a named value is returned, you can put where you like. If an nth value is returned, it has to be added to the end of existing list of items. Otherwise what was the 4th item will become the 5th item.

As the goals are whizzing past.... Is the date and time one value? Is the day a separate value? If both are yes, as a future change, can day and date be combined and time in another with a tab separating them? Should look better. We currently have a gap between day and date.

[Huevos]

I'm not changing any goalposts as I was never part of the discussion.

In timer list the timer is already set, so just showing the position is fine.

In EPG Search the timer hasn't yet been set so maximum info would be a bonus.

I'm saying this from a user point of view though. I realise the coding would be a lot more work, and if it is impractical should be skipped.

[RobvanderDoes]

As a skinner I would prefer every element to be available for skinning as a widget, or a "TemplatedMultiContent" would also be perfect for that. That would give 100% freedom of what to use, how to use it and where to use it.