Beta [Real-time scheduling] schedule without rebooting

Status
Not open for further replies.
'Course not. But I don't need a Slingbox to do the same. With a Slingbox, you don't need RS at all.
Then why would you say: hope I did not find myself in a situation where I could not reboot

When you knew I could not find myself in that situation?

As to not needing rs, I have to say that rs is a much more elegant way to set recordings than the t2 on screen epg. Thanks be to af123
 
I have to say that rs is a much more elegant way to set recordings than the t2 on screen epg. Thanks be to af123
Then you would be better off with RS+RTS than bother with the Slingbox at all. It seems to me you are being deliberately contrary.

Because of the runaway effect. I don't need to take that risk
Risk? What risk - the slight chance of missing a bit of telly? Hardly life threatening, however oppressed we may be by our other halves.
 
Because of the runaway effect. I don't need to take that risk
You don't need to take the risk but I think you are overestimating how big the risk is and the impact of a runaway recording.

While runaways were fairly common in the early days of RTS those problems were quickly diagnosed and solved.
Some runaway occurrences are still reported but they are so infrequent and difficult to reproduce that it has not yet been possible to debug the problem.
There are currently two potential triggers that have been identified:
  • Use of the Foxlink package
  • Scheduling a recording whilst another recording is in progress
I have probably experienced (reported) the most occurrences of the second type of failure but that is only about 3 in a year - far less often than the random hangs which most Humax owners experience, Many users have never experienced a runaway at all.

Whilst inconvenient runaways are rarely disastrous - you often spot an recording that hasn't ended or an unexpected increase in disk usage long before the disk fills (I only have the 512Mb disk). The programme is still watchable and if you want to keep it long term it easy to crop off the surplus.

I think you should give it a go and in the unlikely event that you do experience a runaway you can easily turn RTS off again
 
I have probably experienced (reported) the most occurrences of the second type of failure but that is only about 3 in a year - far less often than the random hangs which most Humax owners experience, Many users have never experienced a runaway at all.
I've not had any. Installed it as soon as it was released.
 
My runaways appear to be linked to scheduling a recording whilst another recording is in progress and even then it is an extremely rare event, 2 or 3 in a year of constant RTS use. I do most scheduling via Remote Scheduling and don't bother to consider whether another recording is in progress.
We record almost everything we watch - several hours a day so the we can remove the ads and time shift programmes to a time convenient to us.

I had not previously made this connection, but I had another runaway today that substantiates it for me.

The scenario is as follows, and is a process I follow at least once a day. This may explain why I have had more runaways than many users.

I log in to RS, my default box (HDR5) shows the pink conflict bar.​
I go into the visual page, and delete one of the conflicting recordings.​
I go back to the Home page (still HDR5)​
I click on the deleted item in the schedule - highlighted blue, so simple to find.​
This takes me to the appropriate area of the EPG and the programme still highlighted​
I switch machines (in this case to HDR2) and select the programme on the EPG​
What I didn't know was that HDR2 was recording at the time. I would have to go from the EPG to the Home page on HDR2 to see that RS reports (assumes) that a recording is in progress.

I don't know if @af123 is still developing RS, but I think some sort of status indication in the banner would be really useful. I realise that RS will only be reflecting the schedule and not actually what the box is doing, but it would still be useful.

Alternatively, could the RS server wait until nothing is recording before releasing the instruction? Or possibly delay RS/sync on the box if it is recording?

 
While it appears that scheduling while recording is slightly more prone to cause runaways in most cases it doesn't cause any problem - if it was reproducible it would have been solved by now.
I don't really like the idea of artificial barriers to work around rare bugs - sometimes you dont want a request delayed
 
Nonetheless it would be handy if the circumstances for a hypothesised possible runaway recording were flagged so that the user could make their own decision, and feedback would then help pin down whether this was the case.

I assume it is the recording in progress that becomes the runaway?
 
I set a recording on HDR3, but it didn't happen. When I had a hunt around to find out why, the WebIF was saying a reboot was required and the RTS enable switch in Advanced Settings was missing (WebIF 1.4.3-3). How can that be? HDR1 still shows the RTS switch in the same version of WebIF.

As far as I know, I had RTS enabled on all three units. Even if I didn't, the switch should still be there without me having to take any specific action - right? Yes, have tried rebooting. nugget is installed.

If left to my own devices I might try force-reinstalling nugget, but guidance would be appreciated especially to figure out why his has happened.
 
Even if I didn't, the switch should still be there without me having to take any specific action - right? Yes, have tried rebooting. nugget is installed.
The option is only there if nugget is installed and "nugget ping" returns "PONG", so checking that would be the first thing to do (and "nugget status" just for good measure).
 
Then check for this:
Code:
humax# opkg files nugget|grep /mod|xargs ls -l
-rwx------    1 root     root         11888 Apr 30 22:55 /mod/bin/nugget
-rwx------    1 root     root         41952 Apr 30 22:55 /mod/boot/2/libnugget.so.install
-rwxr-xr-x    1 root     root           786 Apr 30 22:55 /mod/boot/bootstrap.d/xrts
-rw-------    1 root     root           222 Aug 14  2016 /mod/boot/env.d/nugget
-rwx------    1 root     root           150 May 26  2016 /mod/boot/xinit.d/install_nugget
-rw-r--r--    1 root     root           127 Aug 21  2016 /mod/webif/plugin/nugget/diag.hook
-rw-------    1 root     root            54 Sep  7  2016 /mod/webif/plugin/nugget/diagmeta.hook
-rwxr-xr-x    1 root     root          1325 Aug 25  2016 /mod/webif/plugin/nugget/timers.jim
-rw-r--r--    1 root     root          9358 Aug 17  2016 /mod/webif/plugin/nugget/timers.png
and this:
Code:
humax# ls /mod/boot/2/libn* -l
-rwx------    1 root     root         41952 Jan  1  2000 /mod/boot/2/libnugget.so
-rwx------    1 root     root         41952 Apr 30 22:55 /mod/boot/2/libnugget.so.install
 
Code:
Humax HDR-Fox T2 (HDRFOX3) 1.03.12/3.11

HDRFOX3# nugget ping
Can't connect to nugget, No such file or directory.
HDRFOX3# 
HDRFOX3#

opkg list-installed lists nugget.
 
Code:
HDRFOX3# opkg files nugget|grep /mod|xargs ls -l
ls: /mod/boot/bootstrap.d/xrts: No such file or directory
ls: /mod/boot/2/libnugget.so.install: No such file or directory
-rwx------    1 root     root         11888 Apr 30 22:55 /mod/bin/nugget
-rw-------    1 root     root           222 Aug 14  2016 /mod/boot/env.d/nugget
-rwx------    1 root     root           150 May 26  2016 /mod/boot/xinit.d/install_nugget
-rw-r--r--    1 root     root           127 Aug 21  2016 /mod/webif/plugin/nugget/diag.hook
-rw-------    1 root     root            54 Sep  7  2016 /mod/webif/plugin/nugget/diagmeta.hook
-rwxr-xr-x    1 root     root          1325 Aug 25  2016 /mod/webif/plugin/nugget/timers.jim
-rw-r--r--    1 root     root          9358 Aug 17  2016 /mod/webif/plugin/nugget/timers.png
HDRFOX3#

Code:
HDRFOX3# ls /mod/boot/2/libn* -l
ls: /mod/boot/2/libn*: No such file or directory
HDRFOX3#

Force reinstall?
 
Work to do there... :)
That's curious, I thought they were all up to date. Are you saying I have never had RTS available on HDR3?

Edit: 3.11 makes no difference, HDR1 and HDR4 are also on 3.11. So that's an observation rather than a bug.
 
Umm...

Code:
HDRFOX3# ls -l /mod/boot/2
lrwxrwxrwx    1 root     root          27 Mar 12  2013 /mod/boot/2 -> /var/lib/humaxtv_backup/mod/
HDRFOX3# ls -l /mod/boot/bootstrap.d
HDRFOX3#

I get the impression I should run a disk check (after updating the firmware).
 
Sorry, missed the "/" characters off the ends of those...
The /mod/boot/2/ one points to flash, so won't be affected by anything disk related.
 
Code:
HDRFOX3# ls -l /mod/boot/2/
-rwxr-xr-x    1 root     root       32.5K Jan  8  2017 abduco*
-rwxr-xr-x    1 root     root        6.1K Jan 12  2015 checkpin*
drwxr-xr-x    2 root     root           0 Dec  6  2017 opkg/
-rwxr-xr-x    1 root     root       16.3K Jan 15  2017 tmenu*
drwxr-xr-x    2 root     root           0 May  9 08:58 vdisk/
drwxr-xr-x    2 root     root           0 Dec  6  2017 webshell/
HDRFOX3# ls -l /mod/boot/bootstrap.d/
HDRFOX3#

What should I expect in /mod/boot/bootstrap.d/?
 
Status
Not open for further replies.
Back
Top