Owen Smith
Well-Known Member
Yep can't bleat it.
Almost as good as listening to Bleathoven.
Yep can't bleat it.
Almost as good as listening to Bleathoven.
Thats not what the popup says though:.
Almost as good as listening to Bleathoven.
Or Baahler
I'm back and catching up with the requests and problem reports here and in other threads.
On a side note, the ISP says that they have migrated the RS site to a faster server again and it does feel more responsive to me.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hpkg.tv; s=base;
t=1442497022; bh=ErqqEP1LfgXUQJz33CoQYE9YD/p52e9u34bGP3VZeLc=;
h=Date:Message-Id:From:To:Subject;
b=LHnNzUKY7JIYnXXmQLSPLTK8SuVbdtBZOL+kACXBtBDnhAZchdVtqTMnElyGWZ+Eu
TUwd2a08+aC1RODfvSmc6ixVFMa6u8YlG6xcW8jPPJHlstwOVnIThd6scf6k2ELDdg
LiGBlCxmd6imsASADHYemzccH/mcpS40F1Oke0n0=
Strange, I don't think that DKIM has a means to revoke a key other than removing it from the DNS, and indeed the key is missingFairly obscure nit relating to emails from the RS service.
I recently installed a DKIM signature verifier plugin, in my mail reading app (Thunderbird), and it reports that the RS email has been signed using an invalid "revoked" DKIM key.
% dig any +short base._domainkey.hpkg.tv
"v=DKIM1; k=rsa; t=y:s; p="
% dig any +short base._domainkey.hpkg.tv
"v=DKIM1; k=rsa; t=y:s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWo1gFu530uvZS3mKv5RbnyZE6Hf1W+fVUNyHxlMrknzgmv+PNQ2TNCtn8iB+4D7x1tMjbVVwr5rJ/0edJFS0kx+OY1MeZ2NDoFpHwzQMIHGFrVmQwX+YIgsqDcwivZ83LLTL/rHJywbSfXCF/zbVCTD8jjQW8kWT3h8zm+XGDMwIDAQAB"
You should be going to https://rs.hpkg.tv/ rather than the .hummypkg.org.uk variant.
I noticed this behaviour but I thought that we cannot do anything about it because it's the T2 software which does the conflict checkI have noticed a problem with the recording conflict reporting. I first saw it a few months ago when I lost a series of daily recordings through conflict while I was on holiday. Today it has happened again, I think that I can now see what circumstances cause it.
The symptom is that a recording conflict is not reported and highlighted until the day of the conflict (which may be a bit late to do something about it).
The current example is that I got a conflict between Building Cars Live, Restoring Britain's Landmarks & DIY SOS: Homes for Veterans. The laast 2 are weekly events, but the first occurred just yesterday and today.
I believe that for recurring events, only the first scheduled instance is being checked, so if one event is daily it will not be conflict checked until the day of the conflict. In my particular case, Building Cars Live was on yesterday as well, so it wasn't until today that the conflicting instance was checked and reported.
For weekly events, this isn't a major problem since they only have multiple scheduled instances for one day, so they are simply reported one day later than they could be. For daily events, it means that notice is reduced to just the day of the conflict.
A solution would be to expand all recurring events to their individual scheduled instances before conflict checking is performed.
We can't influence the checking performed by the Humax but the webif and RS have access to the schedule information and could apply additional checking to provide users with advanced warnings of potential conflictsI noticed this behaviour but I thought that we cannot do anything about it because it's the T2 software which does the conflict check
I see. so you think it can be done, this additional check?We can't influence the checking performed by the Humax but the webif and RS have access to the schedule information and could apply additional checking to provide users with advanced warnings of potential conflicts
What I think is irrelevant (ask the wife)I see. so you think it can be done, this additional check?
I thought you were good in this humax coding business.What I think is irrelevant (ask the wife)
What matters is whether af123 thinks that it is feasible / worth doing / interested in doing / has time to do