[webif] 1.5.x

Well I think I've fixed it this time. We'll see come October. Release to follow.
 
When a Favourites list is specified for the EPG, the EPG displays should list channels in the order defined in the list: well, they do, but because the table doesn't wrap like the on-screen EPG it's possible for the first channel in the list, with the lowest favIdx, to be a surprising channel. I guess the solution to that is more care when defining the list, because there is a vestigial scroll-bar on the right of selected favourites in the on-screen Settings>Edit Channels>Edit Favourite List display to show where the top == lowest favIdx is. It's very easy to move groups of channels to get the desired order and start point.

Also, the selected list should be displayed somewhere above the channel table, or All channels.
 
Last edited:
Also, the selected list should be displayed somewhere above the channel table, or All channels.
It would be nice if it was also a selection box so that you could change the epg subset displayed without needing to go to the settings page to change the default.
 
I never use Favourites so have no knowledge of any niggles. I'll leave it to you chaps to come up with a patch!
 
Updated to the webif beta 1.5.2-7 on Sunday and it's now doing the prolonged "
spin.gif
Processing request..." thing just it as did following updating to webif beta 1.4.9-1 - see my post further back in this thread.
I've not yet applied the fix given at the time.
 
The previous "fix" is not relevant now. Did you update jim at the same time? Is there anything in webif-error.log ?
 
It does it for me as well (which is helpful), whilst updating the meta information. Seems to be a 60 second delay twice, but it does complete if you leave it.
This is undoubtedly a jim problem.
 
It does it for me as well (which is helpful), whilst updating the meta information. Seems to be a 60 second delay twice, but it does complete if you leave it.
This is undoubtedly a jim problem.
That's good. The delay here is around 120 seconds.
 
I am throwing my hat into the ring here too. Since updating both my active boxes to the latest beta, I too have a 60-120 second delay. It is the same on both HDRs.
 
It's an annoying backwards incompatibility in Jim due to a change in the default buffering settings (which were effectively undocumented) in the socket streaming functions which are used to update the package and diagnostic meta information.
Now resolved with WebIf 1.5.2-8 although you have to suffer the delays if using the WebIf to update itself. Just let it complete then all will be OK again.
Or use the command line to update - opkg update && opkg upgrade webif
 
Last edited:
Not very long - 5-10 minutes. Then proving which source code commit the problem had come from, testing either side of that one, looking for likely solutions, and composing a bug report took most of the rest of the hour.
 
:) and this time next year!
Sadly you're right, but not to the same degree, and not with the visual schedule. If you look at any service's EPG schedule tonight between 23:00 and 00:00 (as I was last night) you will see it skips a day (last October I think it would've been a duplicate day, between 00:00 and 01:00, but no-one noticed).
The annoying bit is that there's a fix needed in jim as well as in webif, but I've previously fixed the jim problem, execpt that the maintainer didn't see the need so it never got included (I've had another go).
 
Sadly you're right, but not to the same degree, and not with the visual schedule. If you look at any service's EPG schedule tonight between 23:00 and 00:00 (as I was last night) you will see it skips a day (last October I think it would've been a duplicate day, between 00:00 and 01:00, but no-one noticed).
The annoying bit is that there's a fix needed in jim as well as in webif, but I've previously fixed the jim problem, execpt that the maintainer didn't see the need so it never got included (I've had another go).
Not an EPG view that I ever use!

Pleased the Visual display is fixed
 
Back
Top