Visionman has mentioned this before within these forums and stated he was also talking about other PVRs long before Youview came into being. He has stated that running with the buffer full has a tendency to lead to issues on any pvr. Whether it does or not seems to be more down to luck than design. No-one, on any platform, has seemingly been able to create a solution for issues in that scenario.
As a fault introduced by 28.26 and replicated in 29.27 it very much should be getting attention. I never had this issue with the DTRT-1000 and am planning going back to the cul de sac degraded functionality of that box because no effective pause buffer it ruins the way I want to use the box in the morning.
It is wrong to misportray it as a long standing stutter issue when watching at the back end of a buffer (ie 2 hours time shifted back). This is a new fault at the front end (ie Now) viewing point.
I welcome suggestions of experiments I can do to try and shine more light on this. So far the only ways I can stop it are a) A full Factory Reset every 24 hours OR b) Setting the alarm clock for 6am so I can flip channels and have a working pause buffer at 8am OR c) Not recording any programmes at any time I want to use the live pause buffer
Hardly what one would call usage norms for a supposed top range PVR
Is it not possible in the scenarios that have been mentioned that the HDD has reached the limit of its capability?
Imagine the dancing around that the heads have to do in order to read and write more than one stream, whilst deleting the buffer at the same time. I can't.
Is it not possible in the scenarios that have been mentioned that the HDD has reached the limit of its capability?
Imagine the dancing around that the heads have to do in order to read and write more than one stream, whilst deleting the buffer at the same time. I can't.
I wouldn't have thought the HDD would be unable to cope - the Humax Freeview Play boxes can record four channels whilst watching a fifth. Or maybe you're delving into a "how many angels can dance on the head of a pin" kind of discussion.
Is it not possible in the scenarios that have been mentioned that the HDD has reached the limit of its capability?
Imagine the dancing around that the heads have to do in order to read and write more than one stream, whilst deleting the buffer at the same time. I can't.
Indeed, however the exact same HDD has coped no problem from new and has only just started this behaviour since 28.26.
Visionman has mentioned this before within these forums and stated he was also talking about other PVRs long before Youview came into being. He has stated that running with the buffer full has a tendency to lead to issues on any pvr. Whether it does or not seems to be more down to luck than design. No-one, on any platform, has seemingly been able to create a solution for issues in that scenario.
This is the first time I've encoutered this specific issue on any pvr I've owned (and I've owned a few).
This will be my last post on this thread. However feel free to believe it or not.
If a user chooses to run with their buffer full, its normal functions can, and often will, fail. Aberrations abound (for which 'whacko' is my term) and have been around for about 10 years, and so even before YouView was born. IP channels suffer these aberrations too. I was asked to look into these aberrations about 9 years ago, running deliberate test conditions and then asked again 1 year later. Did either test team cure them? Did we heck.
I can't really go into too much detail (sorry). But suffice to say neither DaveGrohl's thread nor Steve K's (this one) have been ignored. But I wouldn't hold your breath, sadly.
So is the Visionman who asked:- Have you considered the possibility you have an individual problem which isn't related to other users? the same Visionman who looked at this nine or ten years ago, when it was clearly very real to him and to others?
And are the problems of Project Kangaroo, or other contemporary initiatives, really so intractable that we can do nothing about them, even today?
‘Have nothing in your houses that you do not know to be useful, or believe to be beautiful’ Wm Morris
Is it not possible in the scenarios that have been mentioned that the HDD has reached the limit of its capability?
Imagine the dancing around that the heads have to do in order to read and write more than one stream, whilst deleting the buffer at the same time. I can't.
I wouldn't have thought the HDD would be unable to cope - the Humax Freeview Play boxes can record four channels whilst watching a fifth. Or maybe you're delving into a "how many angels can dance on the head of a pin" kind of discussion.
A Humax Freeview Play box might be able to record four channels whilst watching a fifth jimb, but would it be able to cope if it was also required to pause live TV with its buffer full?
How many angels can dance on the head of a pin? Presumably all of them, except for the ones who can't dance.
The thing is that the fault has not been introduced by a recent update, it has always been there as mentioned by a number of contributors.
Nope
It does not occur on my DTRT-1000 running 27.50 and it never ever occurred on that on all the previous software builds. It first appeared when I powered up the DTRT-2100 and 28.26
It would help if those that keep dismissing this as some supposed long standing fault would actually back this view by referencing these supposed posts that so describe it.
A PVR demonstrating such a systematically repeatable fault disabling a key function that takes up a whole section (10) of the user manual is not worthy of the name PVR. That some see it and some don't suggests that it is triggered by a combination of (a) machine hardware +(b) software + (c) user settings + (d) usage. I've been doing what I can to get a data set of these variables so this can be investigated so YouView can go sort the software that ultimately needs fixing and meantime users can work round it.
Just denying it's an issue really isn't going to get anyone anywhere
Not dismissing it, or denying it as an issue, just pointing out that there is no causal relationship linking it to a recent software update. It happened to me once many moons ago, I figured that it was because of extended buffer usage, shrugged my shoulders and got on with my life.
Not dismissing it, or denying it as an issue, just pointing out that there is no causal relationship linking it to a recent software update. It happened to me once many moons ago, I figured that it was because of extended buffer usage, shrugged my shoulders and got on with my life.
Did it happen every morning? That's what it does here. Hard to shrug that off.
And the correlation between never seen on 27.50 and always seen on 28.26 and 29.27 strongly suggests a causal relationship
Not dismissing it, or denying it as an issue, just pointing out that there is no causal relationship linking it to a recent software update. It happened to me once many moons ago, I figured that it was because of extended buffer usage, shrugged my shoulders and got on with my life.
You and I (and others obv) use our boxes in different ways. I admire your shoulder shrug attitude to this particular problem. It is however doing my head in, I obv have less patience than you, this is a major problem for me. I take it that your current box doesn't exhibit this behaviour? Or do you mean your current box went wacko once but hasn't since?
The fault is triggered by both the start AND end of a recording with a full buffer
Tested this this morning. At 6.15am fault present due to full buffer and BBC Breakfast just started recording. Killed the buffer by switching channels, waited 2 hours for buffer to fill and functionality was fine right up until until the recording ended at 9.15. Then the pause buffer navigation was all a mess again.
My device/software user setting details triggering this failure are as follows. Can someone who's not seeing this error please point out any mismatches to their config
DTRT-2100/84B08500 Manufacturer S'W : 29.27.0 Component S'W: 3.3.62 (fa13d7) Platform Config: 4047 ISP Config: 2123 (ie BT) Auto Standby: 12 hours (has occurred on other settings) Standby Mode: Always Ready (has occurred on other settings) Antenna Out: On (has occurred when set Off)
Update of the latest detail configuration that still shows this fault
DTRT-2100/84B08500 Manufacturer S'W : 29.36.0 Component S'W: 3.3.82 (717bc8) Platform Config: 4059 ISP Config: 2143 (ie BT) Auto Standby: 12 hours (has occurred on other settings) Standby Mode: Always Ready (has occurred on other settings) Antenna Out: On (has occurred when set Off)
It may well be this fault is on recent build boxes as several see it but none of the known trialists have.
If YouView want me to ship my box to them so they can see for themselves this is very real and not imagined, please contact me as I'm so sick of this fault
Comments
It is wrong to misportray it as a long standing stutter issue when watching at the back end of a buffer (ie 2 hours time shifted back). This is a new fault at the front end (ie Now) viewing point.
I welcome suggestions of experiments I can do to try and shine more light on this. So far the only ways I can stop it are
a) A full Factory Reset every 24 hours OR
b) Setting the alarm clock for 6am so I can flip channels and have a working pause buffer at 8am OR
c) Not recording any programmes at any time I want to use the live pause buffer
Hardly what one would call usage norms for a supposed top range PVR
Imagine the dancing around that the heads have to do in order to read and write more than one stream, whilst deleting the buffer at the same time. I can't.
I wouldn't have thought the HDD would be unable to cope - the Humax Freeview Play boxes can record four channels whilst watching a fifth.
Or maybe you're delving into a "how many angels can dance on the head of a pin" kind of discussion.
Do you mean the fault has been "triggered" by the update rather than "introduced" by the update then?
Have you considered the possibility you have an individual problem which isn't related to other users?
the same Visionman who looked at this nine or ten years ago, when it was clearly very real to him and to others?
And are the problems of Project Kangaroo, or other contemporary initiatives, really so intractable that we can do nothing about them, even today?
How many angels can dance on the head of a pin? Presumably all of them, except for the ones who can't dance.
It does not occur on my DTRT-1000 running 27.50 and it never ever occurred on that on all the previous software builds. It first appeared when I powered up the DTRT-2100 and 28.26
It would help if those that keep dismissing this as some supposed long standing fault would actually back this view by referencing these supposed posts that so describe it.
A PVR demonstrating such a systematically repeatable fault disabling a key function that takes up a whole section (10) of the user manual is not worthy of the name PVR. That some see it and some don't suggests that it is triggered by a combination of (a) machine hardware +(b) software + (c) user settings + (d) usage. I've been doing what I can to get a data set of these variables so this can be investigated so YouView can go sort the software that ultimately needs fixing and meantime users can work round it.
Just denying it's an issue really isn't going to get anyone anywhere
And the correlation between never seen on 27.50 and always seen on 28.26 and 29.27 strongly suggests a causal relationship
The fault is triggered by both the start AND end of a recording with a full buffer
Tested this this morning. At 6.15am fault present due to full buffer and BBC Breakfast just started recording. Killed the buffer by switching channels, waited 2 hours for buffer to fill and functionality was fine right up until until the recording ended at 9.15. Then the pause buffer navigation was all a mess again.
DTRT-2100/84B08500
Manufacturer S'W : 29.27.0
Component S'W: 3.3.62 (fa13d7)
Platform Config: 4047
ISP Config: 2123 (ie BT)
Auto Standby: 12 hours (has occurred on other settings)
Standby Mode: Always Ready (has occurred on other settings)
Antenna Out: On (has occurred when set Off)
DTRT-2100/84B08500
Manufacturer S'W : 29.36.0
Component S'W: 3.3.82 (717bc8)
Platform Config: 4059
ISP Config: 2143 (ie BT)
Auto Standby: 12 hours (has occurred on other settings)
Standby Mode: Always Ready (has occurred on other settings)
Antenna Out: On (has occurred when set Off)
It may well be this fault is on recent build boxes as several see it but none of the known trialists have.
If YouView want me to ship my box to them so they can see for themselves this is very real and not imagined, please contact me as I'm so sick of this fault