Beta [webif] 1.5.0

Status
Not open for further replies.
I still have another 3 jim extension packages - any reason they weren't included in the consolidation exercise?
1663096543806.png
 
Is there a good test?
The WebIf still works, which clearly it does from your screenshot, and nothing else is broken. The only likely thing was wireless-helper, but the dependency was removed in the recent promotion of 2.0 from beta to main repository.
 
I still have another 3 jim extension packages - any reason they weren't included in the consolidation exercise?
Well, jim-cgi and jim-xconv are nothing to do with the official jim distribution/source, so that's why they are separate, but jim-binary is. I guess I thought it's not changed for ages and it doesn't seem to have any version dependence which the others did. It does seem odd now you mention it, so I'll take another look.
What screenshot?
Sorry, I confused MM's post with yours.
On another machine, what the heck does this mean
Weird. I have no idea. I guess it's an opkg funny. Hopefully it's benign and it should go away when the packages are moved to the main repo.
 
Well, jim-cgi and jim-xconv are nothing to do with the official jim distribution/source, so that's why they are separate, but jim-binary is. I guess I thought it's not changed for ages and it doesn't seem to have any version dependence which the others did.
jim-binary only has one other dependency apart from the WebIf, and that is for tvdiary.
@martxw would you be able to change this? Either change jim-binary to jim, or remove it altogether, seeing as you already have a dependency on webif.
 
Just to clarify my upgrade was via automatic upgrade of webif package rather than manually updating the jim package, no problems have been observed,

It makes no difference to me whether the additional jim packages are integrated into the main jim package or not - it was just a curiosity question.
 
jim-binary only has one other dependency apart from the WebIf, and that is for tvdiary.
@martxw would you be able to change this? Either change jim-binary to jim, or remove it altogether, seeing as you already have a dependency on webif.
Just seen this. I'll take a look at removing the direct dependency.
 
Philosophically, if a package is dependent on a facility, is it right to not declare that dependency just because it happens to be a dependency of another dependency? I don't think so.
 
Philosophically you are right, but there is no practical way in this case that it makes any difference (which I why I suggested both options).
Certain liberties have been taken in many packages already regarding this.

Anyway, webif 1.5.0-4 and jim 0.81-3 are ready for testing. It's likely that these will get pushed to the main repository fairly quickly now.

I'll take a look at removing the direct dependency.
I've updated the package dependency/version for local testing. I can update the repository if it saves you a job?
 
I've updated the package dependency/version for local testing. I can update the repository if it saves you a job?
If you don't mind, thanks. File sharing on and off my Humax is a little rusty at the moment.
 
1.5.0-7 released to Beta.
Fixes the disk space calc. when the TSR buffer is disabled, and the annoying behaviour of the checkboxes on the Queue Status page (courtesy of /df) which had been forgotten about until it annoyed me again the other day.
 
  • Like
Reactions: /df
1.5.0-7 released to Beta.
Fixes the disk space calc. when the TSR buffer is disabled, and the annoying behaviour of the checkboxes on the Queue Status page (courtesy of /df) which had been forgotten about until it annoyed me again the other day.
It may be just a coincidence, but the Visual Schedule display on both my boxes has become slightly scrambled. The "day" lines are today showing as "Wednesday, Thursday, Friday, Saturday, Sunday, Sunday, Monday, Tuesday". The data for the last three days are correctly those of the following days respectively.
 
It may be just a coincidence, but the Visual Schedule display on both my boxes has become slightly scrambled. The "day" lines are today showing as "Wednesday, Thursday, Friday, Saturday, Sunday, Sunday, Monday, Tuesday". The data for the last three days are correctly those of the following days respectively.
This is a symptom of the clocks going back this weekend, it was reported last year as well
normal display should resume next week.
 
1 machine with just a weekly 03:30 Monday reminder exhibited the double Sunday problem after upgrading to 1.5.0-7. A similar machine with the same schedule plus Modern Family E4+1 series record was previously upgraded and doesn't show the problem.

The layout of the cells is highly sensitive to rounding errors. If something as gigantic as a reverse hour hits it I can imagine it all blowing up. If we can fix it we should. I suspect that the width of any row or cell that intersects with the affected hour (or 2? hours in spring) needs to be adjusted. The relevant code appears to be in webif/html/sched/visual/index.jim.

See https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca.
 
Last edited:
The double Sunday problem is caused by items 1 and 3 (at least) on that list. I think I've fixed that. Need to test what happens if something's set across the divide...
...seems OK as far as it can be when mixing BST and GMT on the same display.
Update to 1.5.0-9 available now.
 
Last edited:
The double Sunday problem is caused by items 1 and 3 (at least) on that list. I think I've fixed that. Need to test what happens if something's set across the divide...
...seems OK as far as it can be when mixing BST and GMT on the same display.
Update to 1.5.0-9 available now.
This seems to have fixed it. I already had a recording that spanned midnight Sunday/Monday, so I reserved one from 01:30-02.30 on Monday and it stayed OK.
 
Status
Not open for further replies.
Back
Top