• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

https://rs.hpkg.tv/ - Links in remote scheduling email no longer working

As of the last couple of days I am getting the following when clicking on a title in an email created by my rules setup on rs.hpkg.tv
1697545348209.png
Something has presumably broken somewhere as I get the same result from old emails that worked at the time.
Anyone else seen this?
 

Attachments

  • 1697545142011.png
    1697545142011.png
    44.2 KB · Views: 5
I just dragged an email out of my bin and tried it, works fine. Maybe it's been fixed in the mean time?
 
It might help if people posted the actual links that are broken, raw from the email, rather than just pictures of them, or not bothering at all.
"hpkg.tv/xSeven+Years+In+Tibet" - it's not really surprising that doesn't work.
A working one for comparison would be useful too. That may at least point to where the problem might or might not be.
 
Last edited:
doesn't work for me in Chrome.
"Doesn't work" – does that mean a 404 error or something else?

IIRC 404 implies a file is not accessible or does not exist. It might not be accessible if one user's subset is different from another's – our EPG views depend on tuned set.

Not the same I know, but this morning I've had iPad Safari report "Safari cannot open the page because the network connection was lost" when the network connection is fine and it must be something else like an aborted connection at the remote end.
 
This is one of the links that has a problem:


It seems to be a Chrome issue - it works fine in Edge.

Also, the link posted by Rob in the previous message doesn't work for me in Chrome.
I think you are posting about a Foxsat and I moved your original message to the Foxsat Custom firmware section of the Forum. Whilst there may be similarities in your problem it may be confusing if you post in this forum.
 
http://hpkg.tv/xSeven+Years+In+Tibet
redirects to:
https://rs.hpkg.tv/epg_search.html?pterm=Seven+Years+In+Tibet

It looked like an error to me, due to the format, but obviously isn't.

http://hpkg.tv/a23570
redirects to:
https://rs.hpkg.tv/epg_autoevents.html?aid=23570

It's fairly simple to work out what the redirect is doing if something doesn't work using the original link.

All of these work for me on both FF and Chrome (on Windows 10, will try later on Linux) without giving any errors.
People should state browser/platform too in case of trouble.
 
I think you are posting about a Foxsat and I moved your original message to the Foxsat Custom firmware section of the Forum. Whilst there may be similarities in your problem it may be confusing if you post in this forum.
An email is an email and a website is a website - nothing to do with the box. I have tested further and have found that Edge works every time on both Android and Windows 10. Chrome now seems to 404 on Android every time, but work 50% of the time on Windows - All OS versions and browsers are running up to date versions.
 
All those links are giving me 404 with Opera windows 11 with and without my VPN but Firefox works ok.
 
Chrome now seems to 404 on Android every time, but work 50% of the time on Windows
The only thing I can see that looks amiss after the redirect is this:
HTML:
<!doctype html>
<html>
<head>

<title>hpkg.tv Remote Scheduling</title>
<meta http-equiv="expires" value="Thu, 01 Jan 1970 00:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />
<script type=text/javascript src="//code.jquery.com/jquery-1.12.4.min.js"></script>
<script type=text/javascript src="//code.jquery.com/jquery-migrate-1.2.1.min.js"></script>
<script type="text/javascript" src="//code.jquery.com/ui/1.11.4/jquery-ui.min.js"></script>
...
The "//code/jquery.com" stuff is missing "http:" on the start, which means the browser tries to download from
which generates a 404 error from nginx not surprisingly.
 
The "//code/jquery.com" stuff is missing "http:" on the start
Those are protocol-relative URLs which are discouraged these days but they were once the de-facto way to reference CDNs like code.jquery.com (I suspect what's in this file was copied directly from their documentation when I put this together). I'd be surprised if that wasn't being handled properly by modern browsers but there's no reason not to change them, and I've done that.
While testing the links above, I did find a case where things could get a bit confused -- specifically if you click on one of those short links that redirects to a box you don't have access to, and I've fixed that too.

With both of these changes, @Rob Singlehurst are things any better now?
 
Those are protocol-relative URLs which are discouraged these days but they were once the de-facto way to reference CDNs like code.jquery.com (I suspect what's in this file was copied directly from their documentation when I put this together). I'd be surprised if that wasn't being handled properly by modern browsers but there's no reason not to change them, and I've done that.
While testing the links above, I did find a case where things could get a bit confused -- specifically if you click on one of those short links that redirects to a box you don't have access to, and I've fixed that too.

With both of these changes, @Rob Singlehurst are things any better now?
I've just retried the previous links in Chrome and it 404s just as before. Unfortunately Edge now does the same (both on Android). However, it now works on Windows 10 in both Chrome and Edge. It also works on Android using the full redirected link as shown in post 10 above. Probably a caching issue now that will fix itself over time?

On a different, but RS related topic - if you have been able to amend the links, do you have access to the RS server such that you could liaise with David500 on AVForums. He has updated all the channel icons for the original custom software, but can't access RS to fix them on there:

Thread viewable here: avforums.com/threads/foxsat-hdr-new-updated-package-download.2439250
 
I just tried it on my Android tablet (which I've not used to access RS recently if at all) and it's working, so it definitely looks like a caching issue to me.
 
My reading of what af123 said is that:

a) the links in new emails should work, not existing links; and

b) it is browser dependent.
 
My reading of what af123 said is that:

a) the links in new emails should work, not existing links; and

b) it is browser dependent.
If you look at post #10 you'll see how it works (or should). The links embedded in the email are fully formed and in a shorthand format that should be turned to longhand on the rs server. It's this process that's decided not to work properly. I mentioned in post #16 that it works on my tablet, but I've just realised that it uses an old version of Chrome that is not updateable due to it running Android 5.1. I think this shows that it's something to do with changes made to the latest version of Chromium (since Edge and Opera are also exhibiting the same behaviour, but Firefox is not).
 
I've just gone into the Play store and there was an update for Edge. Those links now work in Edge. Coincidence or have they found the issue and fixed it, or will it stop working again later?
 
If you look at post #10 you'll see how it works (or should). The links embedded in the email are fully formed and in a shorthand format that should be turned to longhand on the rs server. It's this process that's decided not to work properly. I mentioned in post #16 that it works on my tablet, but I've just realised that it uses an old version of Chrome that is not updateable due to it running Android 5.1. I think this shows that it's something to do with changes made to the latest version of Chromium (since Edge and Opera are also exhibiting the same behaviour, but Firefox is not).
Those links also give 404 on my Windows 8.1 laptop which is running outdated old Opera 95 .
 
Back
Top