Black Hole
May contain traces of nut
Can do, later.You should be able to install the former without the latter and not break anything. Does anyone want to test it?
Can do, later.You should be able to install the former without the latter and not break anything. Does anyone want to test it?
That seems to be the case.The jim-oo, jim-pack and jim-sqlite3 packages are all then redundant and should be automatically removed as part of the upgrade.
Is there a good test?You should be able to install the former without the latter and not break anything.
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.Is there a good test?
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.I still have another 3 jim extension packages - any reason they weren't included in the consolidation exercise?
Sorry, I confused MM's post with yours.What screenshot?
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.On another machine, what the heck does this mean
Thought so.Sorry, I confused MM's post with yours.
jim-binary only has one other dependency apart from the WebIf, and that is for tvdiary.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.
Just seen this. I'll take a look at removing the direct dependency.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.
I've updated the package dependency/version for local testing. I can update the repository if it saves you a job?I'll take a look at removing the direct dependency.
If you don't mind, thanks. File sharing on and off my Humax is a little rusty at the moment.I've updated the package dependency/version for local testing. I can update the repository if it saves you a job?
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.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.
This is a symptom of the clocks going back this weekend, it was reported last year as wellIt 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.
webif/html/sched/visual/index.jim
.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.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.
Oops! I then adde3d another reservation from 01:30-02:30 on Sunday spanning the actual divide and al;l stayed OK.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.