• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Remote Scheduling? Your recording schedule contains conflicts; shown in pink below.

Hello everyone

Over time, your list of chosen programmes to view increases and as we all start to add entries for those programmes we used to watch many years ago, in the hope that they may at some time be reshown, we have a major issue with rs (Remote Scheduling?) and when we view the schedule list in web-if we get the dreaded

[ Your recording schedule contains conflicts; shown in pink below. ]

This can cause fear and panic at the best of times, but is a real issue that hopefully can be addressed, if we have our boxes set to record with padding (extra time at start and end of recording) this can add an even higher level of stress

Firstly, is there any way of introducing programming conflict awareness, so that if a new schedule is to be set, it can somehow check that there are no conflicts and, if there are conflicts then, rather than going ahead with setting the schedule, an email is sent (overriding the set schedule option), or is highlighted on the rs web page, as sorting before scheduling would seem less stressful than manually resolving after, for example, if an intended scheduling event were to be set before a long standing event, then your already scheduled programme would not get recorded, assuming the other tuner was already recording a scheduled event

Conflicts are easy (though time consuming) to sort when you know they exist, but some may go unnoticed due to being on holiday

Would it be possible to set a schedule event as a priority so it cannot be overridden with a pending schedule that starts recording before a priority event, or wants to start straight after meaning you lose the padding time

If a scheduled recording event is set by the rs web page, can that event be deleted from the box after the event has stopped being broadcast, as its mere presence as a now dormant event can cause issues if at a later date, the same pid is use again for a further rerun

I'm sure and hopeful that others may add their own views on how to develop a fail-safe, conflict free remote scheduling environment
 
For information: the way I deal with this is to receive email alerts to programmes I may be interested in rather than have them automatically scheduled. Then it's up to me.

I have conflicts in my schedule permanently - they resolve themselves because the conflicts are usually minor overlaps. Other conflicts come and go due to EPG changes.

a now dormant event can cause issues if at a later date, the same pid is use again for a further rerun
Can it? Dormant schedule items expire after three months, and the broadcasters are not supposed to re-use CRIDs within that window.
 
I've had one Humax HDR Fox T2 on for quite a few hours and it appeared to freeze, there is entries in error log files, nas a result it missed a recording event

As a regular restart seems to be recommended, (I turn mine to standby when not being used, (not power saving mode)), but I sometimes leave it on to catch up with auto-shrink queued recordings

Is there anyway of having [ Schedule Reboot ] to run a [ Reboot Humax if idle. ] action as a timed action throughout the day rather than having to select it manually
 
Is there anyway of having [ Schedule Reboot ] to run a [ Reboot Humax if idle. ] action as a timed action throughout the day rather than having to select it manually
This would not achieve what you think it does.

I turn mine to standby when not being used
Neither does that.

The problem is this: the native firmware on the HDR-FOX has a tendency to crash, particularly when a network transaction fails in a way which was not accounted for in the design. That means the 'Fox is prone to crashing when it is using the network if the network connection is poor.

Having crashed, the only way out if that is to power-cycle (ie disconnect the mains). No other intervention is available, having a standby scheduled would have no effect. If software could force a scheduled reboot, the software would not be running in a crashed state anyway.

The only intervention available is to use a timeswitch to cut the power for a short period daily, preferably while the 'Fox is in a scheduled standby. With that in place, the unit can still crash... but the duration of the crash is limited to the next power cycle.
 
No other intervention is available, having a standby scheduled would have no effect.
Hello Black hole, I think you may have misread the bit about scheduling an event, it was to schedule a reboot when idle

particularly when a network transaction fails in a way which was not accounted for in the design
Do you have noteworthy examples of what type of network transactions
That means the 'Fox is prone to crashing when it is using the network if the network connection is poor.
Is there anyway to ensure your network connection is not poor and what constitutes a poor network connection
 
it was to schedule a reboot when idle
There's no need for a reboot in uncrashed idle (so long as you are running with RTS), and if it has crashed it can't respond to a schedule entry.

Do you have noteworthy examples of what type of network transactions
Any network transactions. All of them have a chance of failure and crash (due to poor error handling). The "cleaner" your network and Internet, the fewer crashes you will have.

Is there anyway to ensure your network connection is not poor and what constitutes a poor network connection
Avoid Homeplug, but your Internet connection is out your control.
 
Last edited:
I have Wi-fi smart plugs attached to each of my boxes, scheduled to power off for 5 minutes around 5:15.

If I get a “has not been seen ..” email from RS, I can reboot remotely if not at home. Of course the RS email is only relevant if the box is expected to be on.

This may help achieve what you are trying to do.


Sent from my iPad using Tapatalk
 
Back
Top