Code is a Hole
Member
Still getting runaway recordings occurring, schedchk has been removed, is there any further checks to make to ensure no further occurences please
[Real-time scheduling] - Runaway recording
- Thread starter HeadlessChicken
- Start date
MymsMan
Ad detector
Black Hole
May contain traces of nut
Rather than just stop them, we would very much like to know what's causing them.
Code is a Hole
Member
Woke this morning to discover that one of my Humax HDR Fox-T2 boxes was busy swallowing up disk space long after the scheduled recording end time
I notice that the runaway recording issue predates the release of 'schedchk' and was going to do a fresh install from the very beginning
But, not wanting to have to reenter the recording schedule, I was wondering, where on the hard disk are the recording schedules backed up to, but then I thought, what if the recording schedules that are backed up are corrupt
I record a lot off Forces TV, lcn 96, the strange thing is, some recordings experience runaway recording issues, yet others record ok, it seems the most issues arise from recordings that start during the nighttime, though this morning I did see a runaway recording occur on lcn 12, Quest, which started at midnight
I do a weekly maintenance check, which my routine includes clearing the epg data, doing a 'fixdisk' and when rebooted doing a fix-flash-packages, which seems to minimise daily usage issues, though I did get one morning when nothing got recorded due to the system going read-only, a session of fixdisk and was back up and running again, thankfully I double up on some recordings to a different Humax, thankfully
Not sure if it is related, but I sometimes get a freeze if a box is on for an extended period, resulting in the need to do a back switch flick
I notice that the runaway recording issue predates the release of 'schedchk' and was going to do a fresh install from the very beginning
But, not wanting to have to reenter the recording schedule, I was wondering, where on the hard disk are the recording schedules backed up to, but then I thought, what if the recording schedules that are backed up are corrupt
I record a lot off Forces TV, lcn 96, the strange thing is, some recordings experience runaway recording issues, yet others record ok, it seems the most issues arise from recordings that start during the nighttime, though this morning I did see a runaway recording occur on lcn 12, Quest, which started at midnight
I do a weekly maintenance check, which my routine includes clearing the epg data, doing a 'fixdisk' and when rebooted doing a fix-flash-packages, which seems to minimise daily usage issues, though I did get one morning when nothing got recorded due to the system going read-only, a session of fixdisk and was back up and running again, thankfully I double up on some recordings to a different Humax, thankfully
Not sure if it is related, but I sometimes get a freeze if a box is on for an extended period, resulting in the need to do a back switch flick
peterworks
Ye Olde Bowler
Schedule backups are in /mnt/hd2/mod/var/backup
Note: If copying to a windows pc a colon will make the file unreadable. I rename on the Humax before copying (eg, save as 04-05)and, when copied back, rename on the Humax as, eg, 04:05
You can view the contents of the backup file in the backup/schedule section. Be aware that it backs up favourites and will restore them along with the schedule.
Note: If copying to a windows pc a colon will make the file unreadable. I rename on the Humax before copying (eg, save as 04-05)and, when copied back, rename on the Humax as, eg, 04:05
You can view the contents of the backup file in the backup/schedule section. Be aware that it backs up favourites and will restore them along with the schedule.
Code is a Hole
Member
Thank you peterworks
So backing up to a Buffalo TeraStation NAS server should be ok, files would be copied using an ftp client on a Windows 7 PC
What about other settings files or preference files, can they be backed up as simply
Code is a Hole
Member
I have been recording some programmes on two different Humax HDR Fox T2 recorders recently for redundancy and a recording made at midnight suffered the same runaway issue on both boxes, which would indicate a failure of the broadcasted programme not having a stop recording command, is this plausible rather than there being an issue with the Humax
Black Hole
May contain traces of nut
That depends. How long did you let them run on for?
I think, but I'm not sure, if the flag for the next programme (there's no such thing as a stop flag - it's just the programme ID changing) is not received within specified tolerance of the scheduled time it should stop itself. I might be completely wrong about that, but at least it should trigger a discussion.
That certainly applies to the start of the recording: under AR, if the programme ID is not detected within a 15 minute window, the recording is given up and marked "unable to track".
It's horses for courses: auto-padding is more reliable at making recordings because it does not rely on the programme ID, but it cannot track live schedule changes that don't make it to the EPG.
Code is a Hole
Member
In remote scheduling, I have the option to enable AR, so my understanding is that AR is not used as I prefer padding starting five minutes before and ending five minutes after
Not sure if it is meaningful, but one recording reports 'Status Loss of power/OK' while the second reports 'Status Scrambled/Unknown', regarding the loss of power issue, the Humax boxes are plugged into an APC ES700 UPS, which, when the lights flicker or go out completely for several minutes or longer start bleeping due to lack of mains power, but the Humax boxes continue to record or run if playing a recording
Luke
Well-Knwοn Мember
You are correct, there is a safeguard defined which all freeview recorders are supposed to adhere to when using an AR process. The tolerance is 2 hours.
Not for those using padding.
MymsMan
Ad detector
Are these recordings from Forces TV like your other runaways?
Some of the minor channels don't transmit the programme id codes needed for accurate recording and in those cases the Humax switches automatically to timer recordings. I don't know if it is technically possible but I could imagine the Humax getting very confused if the broadcaster transmitted the AR codes for some but not all programmes.
Keep hold of the overrun programme because it should be possible to analyze the recording to see what programme ids were being transmitted were at different points during the recording.
I suspect that would be done using the ffprobe command but I don't know what the magic incantation needed would be, perhaps one of the experts in that area will provide the necessary spells.
As a practical work around it might be worth installing the multimode and specifying that recordings on Forces TV be made using padding mode rather than AR
ALL recordings have the status 'Loss of power/OK' during recording in case there is a power cut, the status is only updated to Normal at normal end of recording. Scrambled can occur if there is interference in the signal or if the Humax loses track of its encryption key.
Black Hole
May contain traces of nut
I suspect multimode must already be installed, otherwise RS could not offer to make a recording AR... which poses a problem: anyone with multimode installed should set AR as the default.
Code is a Hole
Member
No they were broadcast on Quest lcn 12
Sorry, multimode is not installed
Is that similar to deep voodoo, a Xerox engineer I knew kept using the term deep voodoo
If it is going to help, I'll hold on to the runaway recordings, I use Solar-PuTTY to Telnet to the Humax boxes, let me know the magic spell to cast
Black Hole
May contain traces of nut
In which case I'm not sure you can convert schedules to AR at all (regardless of what RS might say). Anyone confirm?
Luke
Well-Knwοn Мember
From post #29 all recordings are using padding.
.
@Andrea Edwards Is that correct?
If the broadcaster did that it would not have any additional adverse effects. The AR process makes use of the existing present/following EIT which is always transmitted. What the AR process does is to have these dynamically changed in coordination with the transmission. As far as the Humax is concerned what it is receiving for programmes where the broadcaster supports AR is no different to the programmes where the broadcaster does not support AR.
Yes you can "change" from padding to AR via RS (without multimode being installed). This does trickle down to the HDR-FOX, and without multimode to override this change will stick.
I presume that you then get the same recording issue that you can do when change from padding to AR via multimode.
Code is a Hole
Member
Are you advising that AR is a better option to using padding, as as far as I can see, AR is only valid for recordings that are fifteen minutes before or thirty minutes after the scheduled time, when it then defaults to scheduled timings
Black Hole
May contain traces of nut
No, I'm not. I am drawing attention to the observations that multimode is liable to cause erratic behaviour if used in combination with auto-padding set as default, and the possibility that RS might also cause erratic behaviour if used to change auto-padding to AR rather than changing AR to auto-padding.
Personally I use AR by routine, but I can well understand somebody else preferring auto-padding. Just don't force any particular recording to AR.
Last edited:
MymsMan
Ad detector
AR is the best solution for channels that support it correctly, it handles the cases when programmes run late due to overrunning sports events or news events. It is bad when they get it wrong or change the scheduled episode.
If the programme doesn't start within the tracking window it fails to record it doesn't default to timings.
On channels without live events to overrun using timing is normally OK but padding can cause conflicts if you have a number of recording stopping and starting at the same time, even with AR I often get conflict popups because one channel is recording the end ads while another channel is about to start recording.
Luke
Well-Knwοn Мember
The "fifteen minutes before or thirty minutes after the scheduled time" is the tracking window that MymsMan referred to in his helpful post #38. (no not his 38th helpful post! MymsMan has previously posted many more that that).
This period is when AR is tracked.
It is the programme status that defaults to the "scheduled timings" when the broadcaster hasn't setup AR support for their channel.
Black Hole
May contain traces of nut
The HDR-FOX drops an AR recording which fails the window, as "failed to track". It might try to reschedule if there is a repeat, but it does not fall back to the scheduled time.