Beta [Real-time scheduling] schedule without rebooting

Status
Not open for further replies.
RTS really paid off today. I was out noon 'til midnight, and forgot to set Autumnwatch. Fortunately the Devolo link hadn't crashed...

Watching it now.
 
Yes, I find it very useful too. To date, I have not experienced any 'runaway' recordings on my HDRs either.

Thank you to all involved in it's creation.
 
Black Hole said:
RTS really paid off today. I was out noon 'til midnight, and forgot to set Autumnwatch. Fortunately the Devolo link hadn't crashed...

Watching it now.
Click to expand...
you could have done it via rs followed by a reboot command. no need for devolo stuff.
 
And another: somebody I know was appearing on local radio and I forgot before I went out - I then triggered a recording remotely via RS EPG. Yet again, based on recent experience, very fortunate that my HomePlug network (encompassing all my HD/HDR-FOXes) is still communicating with my router and thence to the outside world.

No, I haven't seen a runaway recording either, but I suspect I don't encounter the same circumstances.

mihaid said:
you could have done it via rs followed by a reboot command. no need for devolo stuff.
Click to expand...
Well, you've obviously not been keeping up with dispatches. My HDRs are on a HomePlug network implemented with Devolo kit, and they have developed a nasty habit of disconnecting themselves from the wider network (ie the router, WiFi, broadband, etc) while still communicating happy between each other. Thus I can play stuff between 'Foxes without a problem, but if I try to access their WebIFs from a computer/tablet on the rest of the network when they have dropped out I get a blank page and a timeout - I have to reboot the Devolo connected to the router to get them communicating (with me) again.

Had they been in "clique mode" when I was trying to schedule with RS, nothing would have happened - and no, no need to reboot with the RTS facility.
 
Black Hole said:
...forgot to set Autumnwatch.
Click to expand...
Black Hole said:
...I forgot before I went out
Click to expand...
Bit of a pattern developing here! Hope you're not getting doddery :roflmao:.
My HDRs are on a HomePlug network implemented with Devolo kit, and they have developed a nasty habit of disconnecting themselves from the wider network
Click to expand...
I've just kicked my horrid TP-Link Wireless AP/Client Router into touch (with great satisfaction) after it played up once too often and cut my network in half. I've bought proper new kit which will actually work and you can monitor and control (and program!). Fed up with cheap consumer cr@p from China.
And one of my Humaxes crashed today while I was out. I managed to power cycle it remotely. Yeah!
 
af123 said:
Until now, for as long as it has been possible to schedule recordings via the custom firmware web interface, they have been placed into a pending queue and only moved into the main schedule on the next boot or reboot.

With the latest version of the web interface, this limitation has been bypassed with a new setting to enable real-time scheduling:
Click to expand...

This has worked well on two machines without the runaway recording problem. But I just had an oddity on one of the units yesterday: after making a change to a schedule item, the webif acted as if the beta function was disabled: it added the item to a pending queue, highlighted the original entry, and showed a "Restart Required" notice. I made another change to a different entry and all went back to normal: the pending queue, restart notice and highlight all disappeared and the display showed both changes as having been made.
 
Manual schedule restore is still putting up blazing banners that a reboot is required - with RTS, it isn't.
 
It isn't? It certainly is to restore the favourites part and I thought I'd left it putting the restored entries into the pending list.
 
You have me there. I think that when I checked the restored schedule was in the live list, but I can't confirm because I've rebooted since then to run tunefix.
 
No more runaway recordings since the last update?
Starting to look promising!
 
I haven't had ANY runaway recordings on either of my HDRs and I have been using RTS since 'release'. Guess I am lucky.

Loving RTS.
 
I've been using RTS with four machines, from when it was put on general release (as a beta). I had a couple of runaway recordings the first week, but no problems since.
 
prpr got a runaway unrelated to any schedule manipulation which effectively narrowed the problem to one tiny piece of code. I updated nugget to version 0.97-1 on the 17th of December and hoped that would fix it. There have been no reports since then so I'm feeling hopeful!
 
I may have found an obscure bug in RTS (don't know if it reproducible yet). I scheduled a film to record 1-2 minutes after its listed start time. This was a film in two parts (it had the 'green jigsaw' symbol so I presume it was correctly designated in the guide). The event appeared in the scheduled events list (Webif) with the flashing 'AR' symbol to indicate that the unit was waiting for an AR signal to start the recording. After another couple of minutes the recording had still not started to record, and the entry had disappeared from the scheduled events list; the second part of the film was now in the list. When I turned on the TV, the film had been running for a few minutes and I had to manually record first part of it, having missed the start. I thought that normally when a recording is scheduled with RTS, recording starts immediately if it is later than the start time in the EPG? I presume that because the film was in two parts, rather than doing this, the unit waited for an AR signal instead.

Edit. The second part of the film has just started recording correctly.
 
I don't think trying to schedule a recording too near or after it has started is a supportable proposition. I know it does work sometimes, but I see no way to guarantee it. Caveat emptor.

In my experience one can trigger a recording into starting by changing channel to the target.
 
Status
Not open for further replies.
Back
Top