Media & File Server Bundle for the Foxsat HDR - Release 4 - PART 6

I would check what version of the custom firmware you have installed, if it's not v4.1.3, which is the latest, I would upgrade it first.
 
I had upgraded it first but the Freesat Tune didn't seem to be working correctly so I ran a Factory reset and cleared the settings in the custom firmware. Everything's running fine now and the channel editor has cleaned up the EPG. Still wish I could force the HD channels into the SD channels positions.
 
The CF has a disk file system check and repair capability. Before you do this try renaming the time shift buffer file 0.ts to say 0.old. This will force the box to create another buffer file on a different area of the hard disk.
The timeshift buffer re-name worked very well, the Foxsat has been very stable since, thanks Graham
 
The timeshift buffer re-name worked very well, the Foxsat has been very stable since, thanks Graham

Might be worth running the file system check and repair package anyway :)

Pleased it fixed your problem.
 
I have had 4.1.2 installed for a long time and yesterday I upgraded to 4.1.3. The upgrade went fine and it now reports version 4.1.3.
But, in the Package Management - Installed list, I have several packages listed twice (epg, hmt, jim-tcl, service-manager, webif). They have no version number and the button on the right is install.
All other packages are listed once with a version and the button is remove. I've tried clicking on a couple of the install buttons but it has no effect.
How do I overcome this?
 
From the WebIf goto "Documentation", "FAQs", "Duplicate Entries in the 'Package Management' Installed List" and this explains how to remove the duplicate entries.
 
Many thanks. Followed the instructions and its sorted (I used the "vi" editor via telnet, which worked fine).
 
Managed to install raydon V4.1.3 but cannot proceed and I cannot find it with my web browser, ftp or telnet.

upload_2016-10-23_18-8-45.png

I have a Foxsat-HDR I have managed to install the raydon V4.1.3 and completed the installation where the banner is provided above. When I
try to access the Foxsat-HDR using Telnet, or FTP I cannot find it on my network. If I use my router diagnostics then I can see the IP address and can ping it successfully. What channel should I be trying to access the Foxsat-HDR with and is there any other way to enable access over my network?
 
Managed to install raydon V4.1.3 but cannot proceed and I cannot find it with my web browser, ftp or telnet.

View attachment 776526
I have a Foxsat-HDR I have managed to install the raydon V4.1.3 and completed the installation where the banner is provided above. When I
try to access the Foxsat-HDR using Telnet, or FTP I cannot find it on my network. If I use my router diagnostics then I can see the IP address and can ping it successfully. What channel should I be trying to access the Foxsat-HDR with and is there any other way to enable access over my network?

Reboot the Foxsat and clear the cache on whatever browser you are using. Google for the specific browser.
 
Hi, I am new here and looking for help with the custom freeware. Will it work on a HUMAX 9300T ?

many thanks in advance
 
Ok, so I recently upgraded the webif and now I'm seeing this when I go to epg.jim:

"Runtime Error: /opt/webif/lib/rsv.class:52: child killed by signal SIGBUS in procedure 'require' called at file "epg.jim", line 10 at file "/opt/webif/lib/setup", line 6 in procedure 'rsv' called at file "/opt/webif/lib/epg.class", line 13 in procedure 'rsv' called at file "/opt/webif/lib/rsv.class", line 75 at file "/opt/webif/lib/rsv.class", line 52"

and when I visit epg7day.jim:

"Runtime Error: /opt/webif/lib/rsv.class:52: child killed by signal SIGBUS in procedure 'require' called at file "epg7day.jim", line 10 at file "/opt/webif/lib/setup", line 6 in procedure 'rsv' called at file "/opt/webif/lib/epg.class", line 13 in procedure 'rsv' called at file "/opt/webif/lib/rsv.class", line 75 at file "/opt/webif/lib/rsv.class", line 52"

Any ideas how I fix this?

The caveat here is that I'm tunnelling over ssh from abroad thus

ssh -L16384:pvr.address:80 my.home.server

http://localhost:16384/

All I can think is that

- the webif is bust for some reason? I tried opkg install webif --force-reinstall which did not work
- some webif data is bust? I replaced my webif.db with the default one installed with opkg and that didn't have any effect
- I need another port open? 80 isn't enough? Seems unlikely....
- Something is taking too long and being killed with SIGBUS? Too much pending data?

Any thoughts would be much appreciated as I'm abroad and pretty desperate to set some recordings...

Thanks for the wonderful software! My girlfriend gets to watch Strictly wherever we are in the world, which makes me very happy (as I go to the pub while she watches it)!

Neil.
 
Long standing issues, aka stuff I haven't found a solution for using CF

- When setting timers via webif I need to reboot the device to set them. This leaves my pvr in standby mode and inaccessible until the morning housekeeping boot. Is there a fix for this- to boot into non-standby mode?

- Sometimes epg data is not processed and "last epg data" is *months* out of date. This doesn't affect the device UI or recordings in any way. Can I force a "go away and process all the outstanding schedule data" task?

- Various oddnesses relating to DST, though I think these are fixed? I'm looking out for them so will report if they're still evident.

Overall I love the software and it makes my life better (Raydon, I still owe you the rsync-to-NAS tutorial I promised- I haven't forgotten), so I figured I'd try to mop up the few idiosyncrasies remaining.

Thanks,

Neil.
 
Long standing issues, aka stuff I haven't found a solution for using CF

- When setting timers via webif I need to reboot the device to set them. This leaves my pvr in standby mode and inaccessible until the morning housekeeping boot. Is there a fix for this- to boot into non-standby mode?
This is not the expected behaviour. Rebooting via the web interface should bring your box back into a booted state and not in standby. The web interface is merely doing a "reboot" (or perhaps a "shutdown -r now") at the box's operating system level. Unfortunately I can't really think of a reason why yours would shut down into standby and not reboot. Very strange.

- Sometimes epg data is not processed and "last epg data" is *months* out of date. This doesn't affect the device UI or recordings in any way. Can I force a "go away and process all the outstanding schedule data" task?
There are plenty of posts in this thread (and the earlier parts of it) about keeping EPG data up-to-date. This will happen automatically if your Humax is in full standby (i.e. not within 15 minutes of a scheduled recording) at 3am.

You can force an EPG refresh by going into the Guide pages and waiting for the background audio to return and then rebooting the box. I appreciate that you are remote from your Humax but you could achieve this via the Web Interface remote control ...... Press the Guide button, wait 3-4 minutes (to be safe), reboot the box using the "reboot now" plug-in. Although I guess this just brings us full cricle to your first point re. rebooting the box!!

- Various oddnesses relating to DST, though I think these are fixed? I'm looking out for them so will report if they're still evident.
If you are using Nowster's patch to enable HD recordings to be unencrypted, check you have the correct version. An early release of this patch did cause an issue with time zones. Again, there are plenty of posts in this forum pointing to the correct version of this patch (like #122 on this page for example!).
 
Last edited:
Ok, so I recently upgraded the webif and now I'm seeing this when I go to epg.jim:
.......

Any ideas how I fix this?

The caveat here is that I'm tunnelling over ssh from abroad thus

ssh -L16384:pvr.address:80 my.home.server

http://localhost:16384/

All I can think is that

- the webif is bust for some reason? I tried opkg install webif --force-reinstall which did not work
- some webif data is bust? I replaced my webif.db with the default one installed with opkg and that didn't have any effect
- I need another port open? 80 isn't enough? Seems unlikely....
- Something is taking too long and being killed with SIGBUS? Too much pending data?
Given that you started that post with "I recently upgraded the WebIf..." I will assume that everything was working fine before the upgrade. If this is true, and you were accessing it over your tunnel previously then the only real conclusion is, as you say, "the WebIf is bust for some reason".

My suggestion would be a full reset (see posts #124 and #125 above) but appreciate that it might take a bit of courage to do this if remote from the box itself.
 
This is not the expected behaviour. Rebooting via the web interface should bring your box back into a booted state and not in standby. The web interface is merely doing a "reboot" (or perhaps a "shutdown -r now") at the box's operating system level. Unfortunately I can't really think of a reason why yours would shut down into standby and not reboot. Very strange.

Bah! This is the problem with the biggest impact. So as far as you know there's no magic programmatic way of scheduling a "come out of standby event". A cron job?

There are plenty of posts in this thread (and the earlier parts of it) about keeping EPG data up-to-date. This will happen automatically if your Humax is in full standby (i.e. not within 15 minutes of a scheduled recording) at 3am.

Ah ok- there may be but I didn't realise there was a problem with the reliability of that functionality. FWIW my machine is set to standby at 0255 and wake at 0320 and I rarely record something around that time.

You can force an EPG refresh by going into the Guide pages and waiting for the background audio to return and then rebooting the box. I appreciate that you are remote from your Humax but you could achieve this via the Web Interface remote control ...... Press the Guide button, wait 3-4 minutes (to be safe), reboot the box using the "reboot now" plug-in. Although I guess this just brings us full cricle to your first point re. rebooting the box!!

Hah! Rebooting remote servers is something I've been doing for decades. :)

If you are using Nowster's patch to enable HD recordings to be unencrypted, check you have the correct version. An early release of this patch did cause an issue with time zones. Again, there are plenty of posts in this forum pointing to the correct version of this patch (like #122 on this page for example!).

Thanks- again I did not realise there was an updated version of this. I will check. I'm pretty certain that when I installed it it was actually replacing a binary and there was not an official pkg.

Many thanks for the response.

Neil.
 
Given that you started that post with "I recently upgraded the WebIf..." I will assume that everything was working fine before the upgrade. If this is true, and you were accessing it over your tunnel previously then the only real conclusion is, as you say, "the WebIf is bust for some reason".

My suggestion would be a full reset (see posts #124 and #125 above) but appreciate that it might take a bit of courage to do this if remote from the box itself.

Up until the last revision of the webif, it was working fine. I stupidly "upgraded everything pending while I was paying it attention" right before leaving the UK this time. Text-book failed risk management! In my defence, this is the first time ever that updating a package on the box has caused a problem.

I may try a reset- missing Strictly is something the missus may have to live with....

Neil.
 
Various oddnesses relating to DST, though I think these are fixed? I'm looking out for them so will report if they're still evident.
Modified nowster's patch for utc settop-patch_4.0.9utc_mips.opk HERE from my dropbox to save you hunting.
 
Ah ok- there may be but I didn't realise there was a problem with the reliability of that functionality. FWIW my machine is set to standby at 0255 and wake at 0320 and I rarely record something around that time.

No problem with reliability at all. My Humax works perfectly and has done for years.

The box uses a mixture of UTC and Local times (depends on the function it is executing and the data it is storing). For example, the EPG timestamps are all UTC but the recording schedule timestamps are localised. IIRC the housekeeping boot happens at 3am UTC. Which means that during the summer, housekeeping actually happens at 4am local time. Your timers will be running on local time too, so your box won't be in standby for housekeeping during the summer.

Mind you - that's all from memory - don't have access to my Humax right now. I'm sure someone will correct me if I've got that wrong.

Also, if you're having issues with times in general (ref. your question about DST) then this could also be a contributing factor.

Oh - and unfortunately, when the box is in standby the custom firmware isn't running (effectively the OS isn't loaded) so there's no way of forcing the box out of standby (including wake-on-LAN).
 
No problem with reliability at all. My Humax works perfectly and has done for years.

I think we differ on terms. When I say "unreliable" I mean "doesn't do what I expect".

If EPG data is sometimes up to date and sometimes not then that is "unreliable", hence my description. If that behaviour is predictable and something a computer could automatically fix without any action on my part then I guess it's reliably unreliable. :)

I suspect you're meaning "reliability" as in "it doesn't crash".

The box uses a mixture of UTC and Local times (depends on the function it is executing and the data it is storing). For example, the EPG timestamps are all UTC but the recording schedule timestamps are localised. IIRC the housekeeping boot happens at 3am UTC. Which means that during the summer, housekeeping actually happens at 4am local time. Your timers will be running on local time too, so your box won't be in standby for housekeeping during the summer.

Thanks for explicitly describing this. This explains what I've experienced as "unreliability" over the last few years. So for year-round operation it should be set to sleep from 0255 to 0415?

Mind you - that's all from memory - don't have access to my Humax right now. I'm sure someone will correct me if I've got that wrong.

This is very helpful thanks. I've read and searched these forums many times for this kind of info and not found it (maybe can't see the wood for the trees?) which is why I decided to finally just ask for explicit solutions to my problems.

Oh - and unfortunately, when the box is in standby the custom firmware isn't running (effectively the OS isn't loaded) so there's no way of forcing the box out of standby (including wake-on-LAN).

Ok. I wondered whether there was a magic hook the box looks for to trigger it to boot- something in the filesystem maybe.

The weird thing is that after a power cycle it boots. From a reboot or shutdown -r now it doesn't.

Cheers, and many many thanks for your assistance,

Neil.
 
No problem with reliability at all. My Humax works perfectly and has done for years.

I'm making some progress. Looks like /opt/bin/rsv is crashing. I believe you're the author?

# /opt/bin/rsv -p /mnt/hd1/reserve.info
22 1478628000 1478629800 126 c080 SCRID The Simpsons 51856 www.channel4.com/C4HD0041105162151952 www.channel4.com/50026/005|www.channel4.com/50026/006|www.channel4.com/50026/007|www.channel4.com/50026/008|www.channel4.com/38326/009|www.channel4.com/38326/011|www.channel4.com/64408/001|www.channel4.com/64408/002| The Simpsons 1478628000|1478714400|1478800800|1478887200|1478949900|1478952000|1479146400|1479232800| 1478629800|1478716200|1478802600|1478889000|1478952000|1478953800|1479148200|1479234600|
23 1479163500 1479166200 106 c080 SCRID Have I Got a Bit More News for You 40836 fp.bbc.co.uk/VQ9IRW fp.bbc.co.uk/1RKJM2| Have I Got a Bit More News for You 1479163500| 1479166200|
24 1478471400 1478474100 102 c080 SCRID QI XL 39651 fp.bbc.co.uk/UWY6F7 QI XL
25 1478976900 1478981400 106 c080 SCRID Strictly Come Dancing 38592 fp.bbc.co.uk/VO13O7 fp.bbc.co.uk/1REFLL|fp.bbc.co.uk/1REFM3| Strictly Come Dancing 1478976900|1479064500| 1478981400|1479067200|
28 1476216000 1476219600 126 c080 SCRID National Treasure 47509 www.channel4.com/C4HD0160920162143642 National Treasure
Bus error

Ok, interestingly, /mnt/hd1/reserve.info could not be copied elsewhere - read error. Restoring a pre-hk version of this has stopped rsv crashing.

So. In summary, I think rsv was crashing because of a filesystem read error. Whether that means the HD is crashing I will wait and see...
 
I suspect you're meaning "reliability" as in "it doesn't crash".
Not quite ;) I mean "reliable" as in "my EPG is bang up to date every day on both the Humax UI and the Web interface. Day in, day out. With boring, metronomic consistency. Without any intervention from me - ever!".

But then again, I am perhaps a more typical user than yourself. My box is booted out of standby of an evening so that we can watch TV and then put into standby when I retire for the day. It is therefore always in standby for housekeeping, and as I said in my original response, if the box is in standby for housekeeping then there are no issues with automatic EPG updates.

However, I understand the reasons why you want your box to be booted most of the time. Your suggestion of 0255 - 0415 seems reasonable to me. I'm not really sure how long housekeeping takes but can't see it taking any longer than 15 minutes.
 
Not quite ;) I mean "reliable" as in "my EPG is bang up to date every day on both the Humax UI and the Web interface. Day in, day out. With boring, metronomic consistency. Without any intervention from me - ever!".

That's the kind of reliable I like! :)

But then again, I am perhaps a more typical user than yourself. My box is booted out of standby of an evening so that we can watch TV and then put into standby when I retire for the day.

Yeah, living half-abroad means the machine is largely a british TV server for me so I need to be able to schedule recordings and have them execute at almost any time of day.

So this is another question to which I don't have the answer. Does the box record even in standby? My reasons for having it fully on most of the time is so I don't have to worry about when I schedule recording. I don't have to think "I'm scheduling something for 0900 so I must make sure the box is on then". If the scheduled recording went ahead with the box in standby I could leave it so for much more of the day.

Ta,

Neil.
 

The latest video from AVForums

TV Buying Guide - Which TV Is Best For You?
Subscribe to our YouTube channel
Back
Top Bottom