[rs] Remote Scheduling v1

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.
 
I use wildcards quite a bit to try and capture the right show I want to make sure I'm using the correct phrase and not going to miss out on a recording.
 
Almost as good as listening to Bleathoven.

Or Baahler

I'd feel very sheepish if I was you, with those ewe really was scraping the barrel.

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.

Excellent to have you back af123.
 
Fairly 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.

Just thought someone might like to know (if they don't already).

It's not entirely irrelevant; it could cause some pedantic mail hosts to drop the RS email as potential spam.

Code:
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=
 
Fairly 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.
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 missing

Code:
% dig any +short base._domainkey.hpkg.tv
"v=DKIM1; k=rsa; t=y:s; p="

Fixed now, thanks for letting me know!

Code:
% 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"
 
thanks, I was thinking the same about "revoked", having just setup DKIM here, too.

By coincidence, had another RS email this morning, and it was correctly signed.
 
I have been using the very useful Remote Scheduling for some while now and am currently on version rs 1.3.1

Two weeks ago I changed ISP from Demon to VirginMedia. My original email address was locked to Demon so I had to create a new one with VirginMedia and updated my email address in "webif/settings/Settings for rs package." (and change all my other Internet accounts which has been a nightmare!)

Everything was fine for the first week or so and I successfully programmed a few shows but I am now experiencing problems trying to use the remote scheduler with Chrome. When I try to connect to htts://rs.hummypkg.org.uk/ I get the following warning from Chrome

"Your connection is not private
Attackers might be trying to steal your information from rs.hummypkg.org.uk (for example, passwords, messages, or credit cards.) NET::ERR_CERT_COMMON_NAME_INVALID"

If I click on the 'Advanced' option on the page I get

"This server could not prove that it is rs.hummypkg.org.uk; its security certificate is from rs.hpkg.tv. This may be caused by a misconfiguration or an attacker intercepting your connection.
Proceed to rs.hummypkg.org.uk(unsafe)"
(I haven't proceeded yet)

I get similar reports from both Firefox and Internet Explorer (11)

Any ideas please?
 
I 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.
 
I 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.
I 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 noticed this behaviour but I thought that we cannot do anything about it because it's the T2 software which does the conflict 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
 
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
I see. so you think it can be done, this additional check?
 
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
I thought you were good in this humax coding business.

well, since the current situation is that recordings could be missed I would say it should be quite important to resolve, if indeed it can be done. I suffered from it, you did and I'm sure that others too.
 
Back
Top