OP
Black Hole
May contain traces of nut
Last night Horizon was successful, but I have read (in the other place) somebody else failed on the same programme.
-
The forum software that supports hummy.tv has been upgraded to XenForo 2.3!
Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.
AR on a per-recording or per-service basis
- Thread starter Black Hole
- Start date
Horizon, Higgs Boson worked fine for me off Crystal Palace. It does seem more of a region specific issue for the most part rather than the broadcasters got it wrong most of the time.
If not the BBC, Ch4, etc, then it's the company doing the playout (Red Bee) or a localised transmitter issue i.e. not handling the data it's sent very well.
If not the BBC, Ch4, etc, then it's the company doing the playout (Red Bee) or a localised transmitter issue i.e. not handling the data it's sent very well.
OP
Black Hole
May contain traces of nut
It doesn't really matter where the problem is, for some people AR really doesn't work well enough to ditch padding in all but the most extreme situations.
This seems to me to be a perfectly reasonable and rational statement of fact, and yet I'm getting a flaming row about it in "the other place" - just because when anyone says "AR's fine" I provide balance by pointing out that in my experience it is not.
AF's tool set provides the mechanism (or will do when the WebIF is included) to set auto-padding / AR on a case-by-case or station-by-station basis to the user's content, so no longer are we constrained to choose "all AR" or "all auto-padding" - all to the good. When this development started I had presumed that I could white-list BBC, but I have proven to my satisfaction that is not the case. Maybe it will improve.
This seems to me to be a perfectly reasonable and rational statement of fact, and yet I'm getting a flaming row about it in "the other place" - just because when anyone says "AR's fine" I provide balance by pointing out that in my experience it is not.
AF's tool set provides the mechanism (or will do when the WebIF is included) to set auto-padding / AR on a case-by-case or station-by-station basis to the user's content, so no longer are we constrained to choose "all AR" or "all auto-padding" - all to the good. When this development started I had presumed that I could white-list BBC, but I have proven to my satisfaction that is not the case. Maybe it will improve.
Ezra Pound
Well-Known Member
I would stick with padding permanently IF it was possible to auto-detect consecutive recordings on the same channel and disable padding on that basis.
EDIT:- For 'disable padding' please read 'Enable AR'
EDIT:- For 'disable padding' please read 'Enable AR'
oijonesey
Hummy.tv SEO Guru
You BH - sparking off a flaming row? I can't believe that
Now I like AR, and I also like Padding. But which one is best? There's only one way to find out....FIGHT!!!!!!
Can you expand on this? I thought that padding between consecutive programmes was already ignored.
OP
Black Hole
May contain traces of nut
It is. Can you clarify Ezra? Possibly you mean the problem that if the programme change-over is not at the EPG time, you get one of the programmes clipped.
To reprise something I wrote elsewhere:
Auto-padding settings are honoured unless A. the recordings are consecutive on the same station, or B. there are more than two recordings competing. In the cases where auto-padding settings are not honoured:
1. Actual EPG programme time takes priority over any auto-padding time.
2. End padding time takes priority over start padding time.
In the event that more than two actual programme times (as given in the EPG data) overlap, a recording conflict occurs.
To reprise something I wrote elsewhere:
Auto-padding settings are honoured unless A. the recordings are consecutive on the same station, or B. there are more than two recordings competing. In the cases where auto-padding settings are not honoured:
1. Actual EPG programme time takes priority over any auto-padding time.
2. End padding time takes priority over start padding time.
In the event that more than two actual programme times (as given in the EPG data) overlap, a recording conflict occurs.
Ezra Pound
Well-Known Member
You are correct, Padding is ignored but as pointed out, if program 1 runs over by 5 Mins. it is tacked on to the start of program 2 and a few days later it isn't that easy to find which program, program 2 is. AR (working properly) would stop this happening. This is the only problem I can find with Padding, Apart from padding causing overlap conflicts, Which, having thought about it could also be cured by very limited auto switching to AR
OP
Black Hole
May contain traces of nut
I beg to differ, having run a few experiments to determine the logic in post 147 I conclude that padding does not create conflicts. Only actual programme time creates conflicts, as it would if AR were in use.
As a work-around for the top&tail problem, one could join the recordings together with nice-splice and then split them again at the right place.
As a work-around for the top&tail problem, one could join the recordings together with nice-splice and then split them again at the right place.
Ezra Pound
Well-Known Member
Here is a padding conflict that is not present with AR. With padding of 5Mins. at both ends, recording MUX1 and MUX2 from 7PM to 8PM and MUX3 from 8PM to 9PM would require 3 Tuners e.g. a Conflict for 10 Mins. this is allowable using AR when programs are on time
OP
Black Hole
May contain traces of nut
In my tests a setup similar to that did not conflict - the padding got dropped.
grahamlthompson
Well-Known Member
The tests I did using a single tuner HD FOX T2 (no interaction with a second tuner) showed that where two programmes are set consecutively (different or same channel).
1 No clash is reported at reservation setting (where dropping padding still creates a clash then it is reported)
2 The interim padding is dropped with the changeover from one to the other taking place at the epg scheduled time.
This is different to the Foxsat-HDR that also indicates no clash in step 1 but generates a clash message in 2 unless the recordings are from the same channel, when it drops the intermediate padding.
The following is speculation (I don't have a HDR FOX T2 to test).
Because the HDR model uses only one tuner to record two from one mux there are multiple possibilities.
I imagine it will work like this with autopadding (over to owners to find out
)
Say 3 reservations are set from channels X Y and Z and all are on different mux
Times are epg ones not padding adjusted
Channel X set to record say 19:30-22:30 (tying up tuner 1)
Channel Y set to record 20:00-21:00
Channel Z set to record 21:00-22:00
The latter two will then be the same as the HD FOX T2
In the event of Channel Z being on the same mux as Channel X) a guess is that at the changeover tuner 2 will stop recording at the epg time and tuner 1 will then take over recording Channel Z. (Due to the artficially imposed limit of only two simultaneous recordings even though up to 4 is possible).
The difference between AR and Auto Padding for consecutive recordings is that an overun of Channel Y will be recorded using AR (preserving the end at the cost of losing the beginnining of recording Z - most I suspect would prefer this).
1 No clash is reported at reservation setting (where dropping padding still creates a clash then it is reported)
2 The interim padding is dropped with the changeover from one to the other taking place at the epg scheduled time.
This is different to the Foxsat-HDR that also indicates no clash in step 1 but generates a clash message in 2 unless the recordings are from the same channel, when it drops the intermediate padding.
The following is speculation (I don't have a HDR FOX T2 to test).
Because the HDR model uses only one tuner to record two from one mux there are multiple possibilities.
I imagine it will work like this with autopadding (over to owners to find out
Say 3 reservations are set from channels X Y and Z and all are on different mux
Times are epg ones not padding adjusted
Channel X set to record say 19:30-22:30 (tying up tuner 1)
Channel Y set to record 20:00-21:00
Channel Z set to record 21:00-22:00
The latter two will then be the same as the HD FOX T2
In the event of Channel Z being on the same mux as Channel X) a guess is that at the changeover tuner 2 will stop recording at the epg time and tuner 1 will then take over recording Channel Z. (Due to the artficially imposed limit of only two simultaneous recordings even though up to 4 is possible).
The difference between AR and Auto Padding for consecutive recordings is that an overun of Channel Y will be recorded using AR (preserving the end at the cost of losing the beginnining of recording Z - most I suspect would prefer this).
OP
Black Hole
May contain traces of nut
That echoes my observations. I'll take your word for it regarding priorties where AR is concerned.
OP
Black Hole
May contain traces of nut
I set a couple of C4 programmes on AR tonight - guess what... according to WebIF the first is recording already (but the ring is blue).
Now that's interesting: I had a recorded film sitting on pause. As soon as I pressed stop the recording started (about 7 mins late). There is definitely some kind of interaction between AR recordings and what else the box is doing (never seen anything like this with padding).
Now that's interesting: I had a recorded film sitting on pause. As soon as I pressed stop the recording started (about 7 mins late). There is definitely some kind of interaction between AR recordings and what else the box is doing (never seen anything like this with padding).
webif isn't being very clever there, it just shows that the current time is in the scheduled window.
OP
Black Hole
May contain traces of nut
Second programme has started up fine.
OP
Black Hole
May contain traces of nut
No, I use full-fat.
Hi
Just wondering about the mechanics of multimode recording. As the AR/padding settings only get applied after a restart what happens if:
A recording is set using padding as the system default but the channel multimode is set to AR, the Humax is then put into standby. If the Humax isn't restarted prior to the recording scheduled time, is the recording made using padding or AR? I assume it is padding, but wouldn't the multimode service then try and change the recording schedule to AR while it was in progress, and what impact this might have?
Regards
Phil
Just wondering about the mechanics of multimode recording. As the AR/padding settings only get applied after a restart what happens if:
A recording is set using padding as the system default but the channel multimode is set to AR, the Humax is then put into standby. If the Humax isn't restarted prior to the recording scheduled time, is the recording made using padding or AR? I assume it is padding, but wouldn't the multimode service then try and change the recording schedule to AR while it was in progress, and what impact this might have?
Regards
Phil
The multimode system makes the changes during system boot and before the Humax software is started so it won't make any changes whilst the recording is in progress.
I haven't tried this explicitly - I've only changed things which are going to record after a few reboots - but I would expect that the recording would be made in AR.
I haven't tried this explicitly - I've only changed things which are going to record after a few reboots - but I would expect that the recording would be made in AR.