Beta [Real-time scheduling] schedule without rebooting

Status
Not open for further replies.
af123 said:
I'm still unsure if the runaway recordings are completely fixed and I have a slight suspicion that episode skip may not work quite as intended with real-time turned on.
Click to expand...

I was recording a paused show on one channel and used webif to record a series on another channel. That series had 4 recordings in a row. I then used the schedule view on webif to skip the second of the 4 series. As a result all 4 recordings were recorded in a continuous recording lasting 62 minutes, instead of 4x15 minutes recordings. (I use padding). During this 62 minutes the first in the series remained top of the schedule using the remote.; After the recordings were supposed to be finished the box continued recording. When I stopped the recording there were three new recordings in the folder one 62 minutes long and two with a duration of 0minutes with a time corresponding to the time the recordings were stopped.
 
Border said:
I was recording a paused show on one channel and used webif to record a series on another channel. That series had 4 recordings in a row. I then used the schedule view on webif to skip the second of the 4 series.
Click to expand...
Thanks, I haven't actually tested updating the schedule in conjunction with instant record so I'll have to do that.
The current version of RTS (0.94) does not support episode skipping - it doesn't have the necessary logic to update the in-memory structures properly. 0.95 will support this and it's almost ready, I just need to find a couple of hours to finish it off.
 
Nugget 0.95 now available - update your webif too.

Although still definitely a beta, this one seems pretty solid. Lots of internal improvements and a couple of memory leaks have been fixed along the way. Episode skip is now working properly and all of my tests over the past few days have been successful.

There's still potentially a problem with runaway recordings - by which I mean that I haven't done anything specific to fix it but I haven't seen any occurrences either. If anyone does see one then the log and other diagnostic tools I've added should help shed some light on it.

I'm also interested in any times that the schedule fails to reload properly on the first attempt - that's shown in the nugget.log as 'Schedule load failed.' along with more information (hexdump plus some fields). I was seeing a lot of these a few days ago but can't replicate it now I've added the new logging. Again, the log will provide more information if anyone sees this.

I'm sure there are still some other problems so please test this as much as you can and report back. The nugget.log file should be much more useful.

I've added some new commands to the nugget utility. nugget schedule.epg <slot> shows the internal EPG data attached to the recording slot. This should be useful for troubleshooting.
 
af123 said:
I'm also interested in any times that the schedule fails to reload properly on the first attempt - that's shown in the nugget.log as 'Schedule load failed.' along with more information (hexdump plus some fields). I was seeing a lot of these a few days ago but can't replicate it now I've added the new logging. Again, the log will provide more information if anyone sees this.
Click to expand...
Is it possible the Schedule load needs to be slightly later in time and your extra logging is pushing it far enough back to become reliable?
(I had things like that on process control software many years ago which was sorted by putting a 'first scan' skip in.)
 
MikeSh said:
Is it possible the Schedule load needs to be slightly later in time and your extra logging is pushing it far enough back to become reliable?
Click to expand...
In the early versions I had extra delays in various places and even had it do retries with an increasing delay if a load failure occurred. Even with the retries, a failed load kept failing until it was tried from a different thread. This isn't a subtle timing issue or race condition.
The latest version does a schedule save before moving pending entries over to the database and loading it again. That might be what's solved the problem or I might just not have seen it since. When the problem occurs now, we should at least be able to see the SQLITE3 error code stored in the database handle that the Humax software has open.
 
I've had similar occurrences where updating to Nugget 0.95, Web-If v1.3.2-5 and reboot. Adding or removing a programme then causes the Humax to crash. This has occurred on 2 machines consistently. Any logs you want to post let me know.
 
Updated package now available. It looks like the schedule load problem is still there and when it occurs the database handle becomes NULL (hence the crash). It shouldn't be a problem with the new package, there will just be a short delay before the schedule is reloaded.
 
I had a runaway recording overnight. Bram Stoker's Dracula on Film4. What diagnostics should I post?

Web interface version: 1.3.2-5 Nugget v 0.95-1
 
Hopefully the runaway recording issue will soon be resolved, but in the meantime could a safety brake be incorporated into webif to automatically stop recordings after say 210 minutes?

The issue being the successive scheduled recordings skipped on a busy box when a recording does not finish. Especially if not noticed for some time.
 
Last edited:
Status
Not open for further replies.
Back
Top